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Preface 


The OpenVMS AXP Version 6.1 Release Notes manual describes features and 
restrictions of the OpenVMS AXP Version 6.1 operating system. It also provides 
information about operating AXP computers and provides descriptions of features 
that are unique to AXP systems. 

Intended Audience 

This manual is intended for general users, system managers, developers, and 
programmers who use the operating system. It is especially useful for those who 
are about to install the operating system. 

Document Structure 

Chapter 1 provides information about using AXP computers. 

Chapter 2 describes changes, new features, and restrictions that affect some 
commonly used procedures and utilities. 

Chapter 3 describes changes, new features, and restrictions that affect utilities 
used for system and performance management, system maintenance, and 
networking. 

Chapter 4 describes issues pertaining to mixed-version and mixed-architecture 
VMScluster systems. 

Chapter 5 provides information about changes, new features, and restrictions 
that affect areas such as tools, utilities, run-time libraries, system services, and 
the file system. 

Chapter 6 describes corrections to the OpenVMS AXP documentation set. 

Chapter 7 describes Customer Log Desk (CLD) problems that have been fixed 
since OpenVMS AXP Version 1.5. 

Associated Information 

For a list of additional documents that are available in support of this version 
of OpenVMS AXP, refer to the CD-ROM booklet and the Overview of OpenVMS 
Documentation . 

The Alpha Architecture Reference Manual mentioned in this document is 
published by Digital Press under order number EY—L520E—DP. The VMS for 
Alpha Platforms Internals and Data Structures manual mentioned in this 
document is published by Digital Press under order number EY-L466E-P1. 




Conventions 


In this manual, every use of OpenVMS AXP means the OpenVMS AXP operating 
system, every use of OpenVMS VAX means the OpenVMS VAX operating system, 
and every use of OpenVMS means both the OpenVMS AXP operating system and 
the OpenVMS VAX operating system. 

The following conventions are also used in this manual: 


Vl.x 


CtrVx 


PF1 x 

GOLD x 


1 Return 


A margin note beneath each heading indicates the OpenVMS 
AXP version in which the note was first published. All notes 
identified with the V1.0 or VI.5 margin note also apply to 
OpenVMS AXP Version 6.1. 

A sequence such as CtrVx indicates that you must hold down 
the key labeled Ctrl while you press another key or a pointing 
device button. 

A sequence such as PF1 x indicates that you must first press 
and release the key labeled PF1, then press and release 
another key or a pointing device button. 

A sequence such as GOLD x indicates that you must first press 
and release the key defined GOLD, then press and release 
another key. GOLD key sequences can also have a slash (/), 
dash (—), or underscore (_) as a delimiter in EVE commands. 

In examples, a key name is shown enclosed in a box to indicate 
that you press a key on the keyboard. (In text, a key name is 
not enclosed in a box.) 

In examples, a horizontal ellipsis indicates one of the following 
possibilities: 

• Additional optional arguments in a statement have been 
omitted. 

• The preceding item or items can be repeated one or more 
times. 

• Additional parameters, values, or other information can be 
entered. 


A vertical ellipsis indicates the omission of items from a code 
example or command format; the items are omitted because 
they are not important to the topic being discussed. 

( ) In format descriptions, parentheses indicate that, if you 

choose more than one option, you must enclose the choices 
in parentheses. 

[ ] In format descriptions, brackets indicate optional elements. 

You can choose one, none, or all of the options. (Brackets are 
not optional, however, in the syntax of a directory name in 
an OpenVMS file specification, or in the syntax of a substring 
specification in an assignment statement.) 

{ } In format descriptions, braces surround a required choice of 

options; you must choose one of the options listed. 

boldface text Boldface text represents the introduction of a new term or the 

name of an argument, an attribute, or a reason. 

Boldface text is also used to show user input in Bookreader 
versions of the manual. 




italic text 


UPPERCASE TEXT 


numbers 


mouse 

MB1, MB2, MB3 



Italic text emphasizes important information, indicates 
variables, and indicates complete titles of manuals. Italic 
text also represents information that can vary in system 
messages (for example, Internal error number ), command lines 
(for example, /PRODUCER=7zarae), and command parameters 
in text. 

Uppercase text indicates a command, the name of a routine, 
the name of a file, or the abbreviation for a system privilege. 

Hyphens in coding examples indicate that additional 
arguments to the request are provided on the line that follows. 

All numbers in text are assumed to be decimal, unless 
otherwise noted. Nondecimal radixes—binary, octal, or 
hexadecimal—are explicitly indicated. 

The term mouse refers to any pointing device, such as a mouse, 
a puck, or a stylus. 

MB1 indicates the left mouse button, MB2 indicates the middle 
mouse button, and MB3 indicates the right mouse button. (The 
buttons can be redefined by the user.) 
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Running OpenVMS AXP 


This chapter discusses aspects of the AXP operating system environment, 
including installation and upgrade capabilities, running DECwindows software, 
and using AXP computers. 

1.1 Compatibility with Translated Programs and Images 

VI.5 Digital supports translation of programs from VAX VMS Version 4.0 through 

Version 5.4-3. Although the VAX Environment Software Translator (VEST) 
translates Version 5.5 images, OpenVMS AXP Version 1.5 might not provide 
the necessary run-time support because the translated libraries are based on 
Version 5.4-3. In this case, the translated VAX VMS Version 5.5 image may get 
an identification mismatch at run time. 

1.2 Audio Editor in DECwindows Mail 

V6.1 The Audio Editor in DECwindows Mail is not usable on systems running 

DECwindows Motif Version 1.1 and OpenVMS AXP Version 6.1. The following 
error message is displayed when you attempt to create a new mail message with 
the Audio Editor: 

Application Interface library error 0 

To eliminate this problem, install the DECwindows Motif Version 1.2 kit. 

1.3 Obtaining the Console Version From a Running System 

V6.1 The console firmware version number is part of the hardware restart parameter 

block (HWRPB). The console software of the various Alpha AXP platforms passes 
this information to the HWRPB. 

The field SLOT$Q_PAL_REV_AVAIL in the per-CPU slot area points to the start 
of the PAL code revision availability block. The first quadword contains the 
console version. 

Currently, the only way to retrieve this information is to shut down the system 
and examine the console version from the console prompt (»>), because utilities 
have not been updated to return this information from either the running system 
or a crash-dump file. The $GETSYI item code CONSJVERSION currently returns 
zero. 

Future versions of OpenVMS AXP will have the ability to return the console 
version from the running system by using the $GETSYI system service or 
the F$GETSYI lexical function. In addition, the Crash Log Utility Extractor 
(CLUE) will be updated to extract this information from a crash-dump file (CLUE 
CONFIG). 
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1.3 Obtaining the Console Version From a Running System 


Until these updates are available, you can use the System Dump Analyzer (SDA) 
to examine the console version by performing the following commands: 

$ analyze/system 
or 

$ analyze/crash sys$system:sysdump.dmp 

SDA> rad sys$loadable_images:sysdef 
SDA> define hwrpb = @exe$gpq_hwrpb 

SDA> define primary = @(@exe$gpq_hwrpb+hwrpb$iq_primary) 

SDA> define slot_offset = @(@exe$gpq_hwrpb+hwrpb$iq_slot offset) 

SDA> define slot_size = @(@exe$gpq hwrpb+hwrpb$iq_slot_size) 

SDA> examine hwrpb+slot_offset+(prImary*slot_size)+slot$q_pal_rev_avail 

DEC 200/3000 Models: 

Bit <15:8> major version 
<7:0> minor version 

Example: 00000000 00000302 means V3.2 
DEC 4000 Models: 


Bit <15:8> major version 
<7:0> minor version 
<63:32> variant, decimal 

Example: 0000001A 00000305 means V3.5-26 
DEC 7000/10000 Models: 


Bit <23:16> version tag, one byte ascii 
<15:0> major version 
<47:32> minor version 
<63:48> variant, hexadecimal 

Example: 44450002 00580003 means X3.2-4445 

1.4 DEC 2000 Notes and Restrictions 

This section contains notes and restrictions specific to DEC 2000 systems. 

1.4.1 Upgrading Firmware 

The following notes concern upgrading firmware. 

1.4.1.1 Upgrading the OpenVMS Operating System 

V6.1 Prior to upgrading the firmware (and the OpenVMS console) on DEC 2000 AXP 

150 and 300 systems to Version 1.3, you must upgrade OpenVMS to OpenVMS 
AXP Version 6.1. Failure to do so could prevent your system from booting. 

1.4.1.2 Reverting to Earlier Versions of OpenVMS 

V6.1 Version 1.5-1H1 of OpenVMS AXP is incompatible with firmware Version 1.3 and 

above of the DEC 2000 Models 300 and 500. If you upgrade your machine to 
Version 1.3 or above of the firmware, do not attempt to revert to Version 1.5-1H1 
of OpenVMS AXP. If you need to revert to OpenVMS Version 1.5-1H1, you must 
also revert to firmware Version 1.2. 

Failure to do so will result in OpenVMS crashing. 
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1.4.2 SCSI Port Error Count 

V6.1 When the OpenVMS AXP operating system is booted on a DEC 2000 Model 300 

system, SCSI ports labeled PKnO (as listed in the SHOW DEVICE or SHOW 
ERROR display) will show an error count of 1 but will not have the error listed 
in the log file. This is not an actual error, but the result of the SCSI bus reset 
issued in the boot path. 

Switching Console Output 

You can switch your console output to the alternate console or to the graphics 
terminal by using the SET CONSOLE command and specifying either VGA 
(graphics terminal) or serial (alternate console). For example: 

»> SET CONSOLE VGA 

1.4.4 Graphics Support on DEC 2000 Systems 

V6.1 The following notes and restrictions apply to DEC 2000 Model 300 systems with 

graphics: 

• The DEC 2000 Model 300 computer supports only a single QVision video card. 

• Graphics will not work if you boot the system using the alternate console. 
Only the console for graphics (with keyboard and mouse input) is supported. 

• When you boot the system from the graphics console, the serial lines do not 
work, nor can you press Ctrl/P to halt the system. (Although Ctrl/P will halt 
the system, the keyboard will not be left in the correct state. Press the Halt 
button instead.) 

• If the window system is active, halting the system and then entering the 
console command CONTINUE is not supported. 

• Note the following about the console window: 

— The console window is full screen (VGA mode) and when active, the server 
operation is suspended until the console window is removed. 

- Because the server is stalled by the console, a logical is available that 
allows you to remove the console window automatically after a specified 
number of seconds. 

This feature is not enabled by default. To enable the feature, define the 
server logical (in DECW$PRIVATE_SERVER_SETUP.COM) as follows: 

DEFINE/SYS DECW$SERVER_AUT0_C0NS0LE_REM0VE n 

where: 

n is the number of seconds you want the console window to be visible 
before it is removed. 

— The console window is 24 lines by 80 columns. The 25th line contains one 
of two possible displays. When the window system is active, the following 
message is displayed: 

OpenVMS AXP Operator Console - Ctrl+F2 to Resume the Window System 
When the window system is not active, the following message is displayed: 
OpenVMS AXP Operator Console 


1.4.3 

V6.1 
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You can customize or internationalize the messages by defining the server 
logicals (in DECW$PRIVATE_SERVER_SETUP.COM) as follows: 

DEFINE/SYSTEM DECW$SERVER_ACTIVE_STATUS_LINE "text-for-active-window-system-message" 
DEFINE/SYSTEM DECW$SERVER_NOT_ACTIVE_STATUS_LINE "text-for-inactive-window-system-message" 

- The server implements a fast 0-width line drawing algorithm that uses 
the QVision drawing engine at full speed. Due to a hardware problem, 
lines may not be correct for the last pixel of lines using CapNotLast. 

You can choose accurate semantics but the drawing performance will 
be 10 times slower (0-width lines do not need to be accurate). To 
draw end pixels correctly for 0-width lines, define the server logical 
(in DECW$PRIVATE_SERVER_SETUP.COM) as follows: 

DEFINE/SYSTEM DECW$SERVER_USE_SLOW_VGA TRUE 

1.4.5 DEC 2000 Model 100 Ethernet Cable Selection 

V6.1 For DECchip 21040-AA Ethernet devices, labeled EWA0, EWB0, and so on, 

the Ethernet cable connection is selected by means of a console environment 
variable called EWA0_MODE, EWB0_MODE, and so on. The Ethernet driver, 
SYS$EWDRIVER.EXE, uses two selections, AUI or TWISTEDPAIR. To select 
AUI mode (10Base2 or 10Base5) for EWA0, type the following command at the 
console prompt SET EWAO_MODE AUI. To select twisted pair (lOBaseT), type SET 
EWAO_MODE TWIST. To display the selections, type SHOW *_M0DE. 

1.4.6 Serving Diskettes on DEC 2000 Systems 

V6.1 Effective with OpenVMS AXP Version 6.1, serving diskettes is not supported for 

DEC 2000 systems. 

1.4.7 Terminal Devices Supported 

Table 1-1 lists the supported terminal devices for the Digital 2100 Server Model 
A500/600 MP and the DEC 2000 Model 300. 


Table 1-1 Supported Terminal Devices 


Terminal 

Interface 

No.of 

Lines 

Outout 

Silo DMA 

Split 

Speed 

Bus 

International 

Modem Control 

Digital 2100 

Server Model 
A500/600MP 

2 

No 

No 

No 

None 

Full 

Digital 2100 

Server Model 
A500/600MP 1 

4,8 

Yes 

No 

No 

EISA 

Full 

DEC 2000 

Model 300 

2 

No 

No 

No 

None 

Full 

DEC 2000 

Model 300 1 

4,8 

Yes 

No 

No 

EISA 

Full 


1 Optional multiplex serial DIGIboard PC/X™ adapter card. You can daisy chain up to 4 boards in one system, resulting 
in 16, 32, or 64 ports. 
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1.5 Running OpenVMS AXP Using a DEC 7000 Model 600 AXP Computer 

1.5 Running OpenVMS AXP Using a DEC 7000 Model 600 AXP 
Computer 

V1.0 The following sections discuss features and problems related to DEC 7000 Model 

600 AXP computers. 

1.5.1 SCSI Support 

VI.0 The host ID is 7 for ports A and B of the KZMSA-AB SCSI controller. 

1.6 Switching Between Operating Systems on Alpha AXP 
Computers with EISA Buses 

V6.1 Because configuration files are different for each operating system, you must 

do the following to switch from one operating system to another on Alpha AXP 
computers equipped with EISA buses (such as DEC 2000 Model 300 and 500 or 
Digital 2100 Server Model A500MP and A600MP systems): 

1. Insert the diskette that contains the configuration files for the operating 
system you are going to switch to. 

2. Run the EISA Configuration Utility (ECU) from that diskette. 

3. Remove the ECU diskette. 

4. Switch operating systems by following the procedure described in the 
hardware user’s or technical manuals supplied with your computer. 

1.7 POSIX Availability 

V6.1 OpenVMS AXP Version 6.1 will be FIPS 151-2 certified and XPG4 branded by 

POSIX for OpenVMS Version 2.0, which will be included on the the Q3 CY94 
layered products CD-ROM for AXP systems in August 1994. A beta-test version 
of POSIX for OpenVMS Version 2.0 will be available for those customers who 
have a critical need for the POSIX for OpenVMS functionality in the interim 
period. Customers should contact their local CSCs. 

1.8 SCSI Disk Class Driver (DKDRIVER) — Restriction Removed 

V6.1 The restriction on the SCSI disk class driver (DKDRIVER), that it did not 

support data check operations for OpenVMS AXP Version 1.0, has been removed. 
The comparison operations invoked by the IO$M_DATACHECK modifier, the 
IO$_WRITECHECK function code, and other requests for data check support now 
function correctly. 

1.9 Token Ring Support 

V6.1 OpenVMS AXP Version 6.1 includes support for 802.5 standard Token Ring LANs. 

This support provides both hardware and software support. The QIO interface 
for Token Ring is documented in Chapter 9 of the OpenVMS I/O User's Reference 
Manual. The Token Ring LAN hardware supports both 4 and 16 Mbit/s ring 
speeds, and provides both shielded twisted pair (STP) and unshielded twisted 
pair (UTP) connections. 

It should be noted that Token Ring is not exactly like either CSMA/CD or FDDI 
data links. For example, a feature of the Token Ring hardware makes the use 
of standard globally assigned group addresses impossible. To work around this 
feature, functional address to globally or locally assigned group address mapping 
has been implemented (see Section 1.9.5). This feature of the Token Ring 
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1.9.1 

V6.1 


1.9.2 

V6.1 


1.9.2.1 

V6.1 


1.9.2.2 

V6.1 


hardware also makes router/bridge configuration require manual intervention 
(see your router/bridge vendor documentation). 

The OpenVMS AXP Token Ring drivers start with source routing enabled by 
default. If you have a transparent bridge (standard IEEE 802.Id), you should 
disable source routing on the adapter (see Section 1.9.6). Source routing is a 
data link protocol for performing end node routing through non 802.1 standard 
bridges. More information on source routing may be found in the OpenVMS I/O 
User's Reference Manual or in the latest IEEE 802.5 drafts. 

Cable Precaution 

The supported Token Ring LAN adapters provide standard shielded twisted pair 
(STP) connections and unshielded twisted pair (UTP) connections. UTP cables 
require that pairs 3&6 and 4&5 are connected without crossover (BN25G or 
BN26M cables). BN26K cables will not work with Token Ring. More information 
about wiring is contained in the documentation that is shipped with the Token 
Ring LAN adapter. 

Hardware Support 

Support is provided for the following devices: 

• DEC TRNcontroller 700 

• ProNET-4/16 EISA NIC 

DEC TRNcontroller 700 

The DEC TRNcontroller 700 (DETRA) LAN device connects to the 
TURBOchannel bus on any DEC 3000 class machine. The device type for the 
DETRA is DT$_IC_DETRA. 

The DETRA is supported by SYS$ICDRIVER.EXE. Its device name is IC cu, 
where c is the controller and u is the unit number (for example, ICAO). 

Setting Default Speed on DEC TRNcontroller 700 

The default speed for the DETRA is 16 Mbits. This may not work for all rings. 
This default can be changed in the hardware. To set the speed of the DETRA in 
NVRAM on the board, type the following at the console prompt (»>): 

»> T TCx EEPR0M WR_SPEED "SPEED=4" 

or 

»> T TCx EEPR0M WR_SPEED ,, SPEED=16" 

where x is the number of the PMAT-AA device in the display listed when you type 
»> SHOW CONFIG. 

ProNET-4/16 EISA NIC 

The ProNET-4/16 (DW300-AA) and ProNET-4/16+ (DT424) EISA Network 
Interface Card connects to the EISA bus on any AXP based system supporting 
the EISA bus. The device type for the DW300 and DT424 is DT$_IR_DW300. 

The DW300 and DT424 are supported by SYS$IRDRIVER.EXE. The device name 
for these devices is: IRczz, where c is the controller and u is the unit number (for 
example, IRAQ). 
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ECU Usage 

You must run the ECU program prior to using this device in an AXP system. See 
your system documentation for information on how to run the ECU. Note that the 
features configured in the ECU (ring speed, line media, early token release, and 
so on) are not honored when the OpenVMS system is started up. The function of 
the ECU for these devices is only to inform the system that this device is resident 
on the system, and it allows the ECU to arbitrate the IRQ values. 

1.9.3 Software Support 

V6.1 Token Ring required major new additions to OpenVMS for support. Some 

required features of the Token Ring hardware required intervention that does not 
occur in current LAN applications. Therefore, a new utility LANCP was created 
to provide simple commands to perform any required manual intervention. 

LANCP Program 

To run this utility, type: 

$ RUN SYS$SYSTEM:LANCP 

This program provides simple set and show commands for common LAN devices 
as well as supplying the Token Ring specific commands. Online help exists for 
the commands available to LANCP. Access help by typing: 

LANCP> HELP 

1.9.4 Address Notation 

V6.1 Common notation for Token Ring LAN addresses is to show those addresses in 

their native bit-reversed format (MSB). OpenVMS deals with all LAN (CSMA/CD, 
FDDI, and Token Ring) addresses in canonical (LSB) format. Where addresses 
are to be specified or displayed in LANCP, the following conventions are used: 

A hyphen ( - ) separating hexadecimal digits represents canonical form 
addresses (for example, 03-00-80-00-00-00). 

A colon ( : ) separating hexadecimal digits represents bit-reversed addresses 
(for example, C0:00:01:00:00:00). 

Functional Address Mapping 

Token Ring hardware does not support IEEE 802 standard globally defined group 
addresses. The hardware supports 30 functional addresses, which are locally 
administered group addresses. The first two bytes of the functional address are 
03-00 (canonical) or C0:00 (bit reversed). The following four bytes contain one bit 
that indicates which functional address is being used. 

OpenVMS AXP Token Ring LAN drivers come with a set of predefined globally 
defined group address to functional address mapping. These addresses are 
documented in the OpenVMS I/O User's Reference Manual. 

To show the current mapping setup, type the following command: 

LANCP> SHOW DEVICE/MAP token_ring_devname 

To define or change a mapping entry, type: 

LANCP> SET DEVICE/MAP=(MULTICAST=mca,FUNCTI0NAL=fa) token_ring_devname 


1.9.5 

V6.1 
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For example, the following command defines the loop assistance multicast address 
to map to functional address 03-00-00-80-00-00: 

LANCP> SET DEVICE/MAP=(MULTI=CF-00-00-00-00-00,FUNC=00:01:00:00) IRAO 
If the entry exists, it will replace the current definition. 

1.9.6 Source Routing 

V6.1 Source routing is enabled by default. Source routing allows the end node to 

perform LAN routing through specific bridges. This is most common in Token 
Ring LANs. However, if you have a transparent capable bridge (and desire to 
use it as such), it would be to your advantage to turn off source routing on your 
Token Ring LAN adapter. To turn off source routing, issue the following LANCP 
command: 

LANCP> SET DEVICE/NOSOURCE token_ring_devname 

1.9.7 Media and Speed Settings 

V6.1 The DETRA is capable of automatically determining which cable port to use 

during operation. However, the DW300 and DT424 do not have this capability, 
and default to the STP interface. 

The DETRA is capable of saving set speed in NVRAM (see Section 1.9.2.1). 
Again, the DW300 and DT424 do not have this capability, and default to 16 
Mbits. 

To change the media and speed setting, from LANCP type: 

LANCP> SET DEVICE/SPEED=4/MEDIA=UTP token_ring_devname 

Include the LANCP commands in your system startup command file if you want 
them to take effect across system restarts. 

1.9.8 Early Token Release 

V6.1 Early Token Release applies only to rings running at 16 Mbits/s. This is a 

performance-improving feature. The default of this setting is enabled. To disable 
this, type the following LANCP command: 

LANCP> SET DEVICE/NOEARLY token_ring_devname 

Again, be sure to put this in your system startup command file if you want it to 
take effect across system restarts. 

Warning to Applications 

Client applications wishing to utilize Token Ring should be careful when enclosing 
LAN addresses inside the data portion of the LAN packet. OpenVMS LAN drivers 
deal with LAN addresses in canonical format, but that does not mean that all 
other systems do. It is best not to enclose a LAN address within the data portion 
of a packet, but if you do, be careful to put the format of address (bit-reversed or 
canonical) that works for your application. 


1.9.9 

V6.1 
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1.9.10 

V6.1 


DECnet Phase IV Usage 

DECnet Phase IV is not supported on the Token Ring devices. However, to use 
DECnet over a Token Ring device, you can use the following sample commands: 

$ MCR NCP 

NCP> DEF LINE MNA-0 STA ON 
NCP> DEF CIRC MNA-0 STA ON 
NCP> EXIT 

$ DEFINE/SYSTEM EXAO IRAO: 

$ 0STARTNET 

The DEFINE/SYSTEM command equates the Token Ring device to the DEMNA 
Ethernet device, which DECnet Phase IV recognizes. This is not supported. 
Note that after you enter the define line and circuit commands, you only need 
to include the DEFINE/SYSTEM command prior to the @STARTNET invocation 
in your system startup command file for the change to take effect across system 
restarts. 
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This chapter contains information for all users of the OpenVMS AXP operating 
system. It includes information about commonly used utilities, text processing 
utilities, and user-environment testing. 

2.1 DCL Commands and Utilities 

This section contains information about DCL commands and utilities. 

2.1.1 DIFFERENCES Command Enhancements 

V6.1 The DIFFERENCES command has been enhanced to support the 

/IGNORE=CASE qualifier. This new qualifier causes the DIFFERENCES utility 
to do a case-blind comparison when comparing records from different files. 

In addition, the DIFFERENCES utility has been enhanced to support the new 
/PAGE implementation described in Section 2.1.7. 

2.1.2 DIRECTORY Command Enhancements 

V6.1 The DIRECTORY command has been enhanced with the following qualifiers: 


Qualifier 

Action 

/EXACT 

Used with /SEARCH to do a case-sensitive search 
when string is enclosed in double quotes (""). 

/HIGHLIGHT=[BOLD] 

[BLINK] 

[UNDERLINE] 

[REVERSE] 

Used with /SEARCH to determine the style 
of highlighting. Options may be combined by 
separating them with commas. 

/PAGE=SAVE[=ti] 

Use new /PAGE implementation when outputting 
information. Save up to n screens of information. 
The default value for n is 5. 

/SELECT=[[NO]ACL] 

Selects files for output that do [not] have ACLs 
associated with them. 

/SELECT=FILE=[[NO]NODE] 

[[NO]DEVICE] 

[[NO]DIRECTORY] 

[[NO]NAME] 

[[NO]TYPE] 

[[NOJVERSION] 

Selects fields of the file specification to be output. 
All fields are output by default. Intended for use 
with the /BRIEF qualifier. Incompatible with the 
/FULL qualifier. 


Also see Section 2.1.7 for a description of the new /PAGE=SAVE implementation. 
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2.1.2.1 Restrictions 

V6.1 The /SELECT=FILE qualifier is incompatible with the /FULL qualifier. 

2.1.3 EDIT Command 

V1.0 The default editor for the EDIT command has been changed from EDT to 

TPU. Therefore, when you enter the EDIT command, the Extensible Versatile 
Editor (EVE) is invoked rather than the EDT editor. In the interest of upward 
compatibility, the EDT editor and callable EDT will continue to be provided, but 
without support, with OpenVMS AXP. Digital urges EDT users to migrate to EVE 
at their earliest convenience. 

The EDIT command now invokes TPU with the EVE section file. Please see 
Section 2.2 for DECTPU and EVE release notes. See the Guide to the DEC Text 
Processing Utility and the OpenVMS Users Manual for more information about 
DECTPU and EVE. 

Retaining the EDT Editor 

To continue using the EDT editor, define the following symbol interactively or in 
your login command procedure: 

$ EDIT :== EDIT/EDT 

This symbol overrides the default and causes the EDIT command to invoke the 
EDT editor instead of EVE. 

DCL Command Procedures and the EDIT Command 

Verify that the /EDT qualifier is present in any DCL command procedure that 
relies on EDT. Any procedure that uses the EDIT command without the /EDT 
qualifier will fail because this verb now invokes TPU with the TPU$SECTION 
section file. (By default, this section file is EVE.) 

EVE and the EDT Keypad 

In EVE, you can select an EDT-like keypad by defining the logical name 
EVE$KEYPAD to be EDT. See EVE documentation for details about how to 
do this at either the process level or system level. 

System managers can find an example of how to define EVE$KEYPAD at the 
system level in the file SYS$STARTUP:SYLOGICALS.TEMPLATE. 

2.1.4 EDIT/FDL Command 

V6.1 The following corrections have been made to the EDIT/FDL command: 

• EDIT/FDL now allows data compression on nonstring keys. 

• A data record compression question is now independent of a key type. 

• EDIT/FDL/NOINTERACTIVE now returns input error status. 

• EDIT/FDL adds missing areas on ADD KEY and TOUCHUP. 

• A Touchup script now desegments keys if requested. 

• The DCL qualifier /NUMBER_KEYS now works with EDIT/FDL. 

_Note _ 

One consequence of these changes is that the Query scripts have changed 
slightly. 
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2.1.5 F$GETDVI — New Return Item 

V6.1 The F$GETDVI lexical function has added the DEVICE_TYPE_NAME item to 

the list of items returned. This item returns a string indicating the name of the 
device type. 

2.1.6 F$GETSYI and $GETSYI: New Item Code REAL_CPUTYPE 

V6.1 A new item code, REAL_CPUTYPE, has been added for the $GETSYI system 

service and the F$GETSYI lexical function. When this item is specified, $GETSYI 
returns the actual CPU type of the primary CPU of the system. 

This new item code replaces the existing CPUTYPE item, which now has a 
new meaning: if the behavior of the actual CPU of the system is modeled after 
another compatible CPU, the type of the later one is returned with CPUTYPE; 
otherwise, the actual CPU type is returned. 

This item code is not included in either the OpenVMS DCL Dictionary or the 
OpenVMS System Services Reference Manual for OpenVMS Version 6.1. 

2.1.7 /PAGE Qualifier — New Implementation 


A new implementation of the /PAGE qualifier has been provided for the following 
commands: 

AUTHORIZE SHOW 

SHOW ERROR 

DIRECTORY 

SHOW LICENSE 

DIFFERENCES 

SHOW LOGICAL 

DUMP 

SHOW MEMORY 

HELP 

SHOW PROCESS 

SEARCH 

SHOW QUEUE 

SHOW AUDIT 

SHOW SYSTEM 

SHOW DEVICE 

SHOW USERS 

SHOW ENTRY 

TYPE 


This implementation prompts you after one screen of information is displayed. In 
response, you can press any one of the following keys: 


Key 

Return 

Enter 

Space 

Ctrl/Z 

F10 

Left Arrow 
Right Arrow 
Down Arrow 
Up Arrow 
Ctrl/W 


Action 

Continue outputting lines. 

Same as Return. 

Same as Return unless in help mode. 

Exitfrom application. 

Same as Ctrl/Z. 

Display last column scrolled off right of screen. 
Display last column scrolled off left of screen. 
Display last line scrolled off bottom of screen. 
Display last line scrolled off top of screen. 
Repaint the screen. 
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Key 

Action 

Find (El) 

Change search string. (Not supported with the 
SEARCH command.) 

Insert Here (E2) 

Display last group of columns scrolled off left of screen. 

Remove (E3) 

Display last group of columns scrolled off right of 
screen. 

Select (E4) 

Toggle 80/132 column mode. 

Prev Screen (E5) 

Display last page scrolled off top of screen. 

Next Screen (E6) 

Display last page scrolled off bottom of screen. 

Help (F15) 

Display help on specified topic. (Not supported for the 
HELP command.) 

Do (F16) 

Toggle display to oldest or newest page. 

Any others 

Ignored (except for the TYPE command; see OpenVMS 
DCL Dictionary: N-Z for details). 

If there is no more text to be displayed in the direction requested, the terminal 
bell sounds. 

When /PAGE mode is used, the following qualifiers are also allowed: 

Qualifier 

Action 

/EXACT 

Used with /SEARCH to do a case-sensitive search 
when string is enclosed in double quotes (""). 

/HIGHLIGHT=[BOLD] 

[BLINK] 

[UNDERLINE] 

[REVERSE] 

Used with /SEARCH to determine the style of 
highlighting. Options may be combined by separating 
them with commas. 

/PAGE[=SAVE [=/i]] 

Use /PAGE implementation when outputting 
information. Save up to n screens of information. 

The default value for n is 5. 

/SEARCH=s£rmg 

Highlight any line containing the variable string. (Not 
supported with the SEARCH command.) 


2.1.7.1 Restrictions 

V6.1 The following restrictions apply to the /PAGE qualifier: 

• The HELP command does not support the HELP key. 

• The SEARCH command does not support the /SEARCH qualifier or the FIND 
key 

• The TYPE command requires the /PAGE=SAVE qualifier to use the new 
/PAGE implementation. Specifying TYPE/PAGE will result in the old page 
behavior, which is compatible with previous versions of OpenVMS. 

• The TYPE/PAGE=SAVE command is implemented using the OpenVMS Screen 
Management Run-Time Library (SMG$). Because SMG$ does not support the 
display of all possible escape sequences, files containing escape sequences that 
are output with the TYPE/PAGE=SAVE command may not appear to display 
correctly. This is a permanent SMG$ restriction. 
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2.1.8 


PRINT/NOTIFY and SUBMIT/NOTIFY Commands 


V6.1 In OpenVMS Version 5.5-2, a problem existed with the PRINT/NOTIFY and 

SUBMIT/NOTIFY commands. When you printed or submitted a job to a generic 
queue with the /NOTIFY qualifier, the notification message incorrectly displayed 
the name of the generic queue on which the job completed. This behavior 
was inconsistent with versions earlier than OpenVMS Version 5.5, where the 
notification message displayed the name of the execution queue on which the job 
completed. 


This problem has been corrected. When you print or submit a job to a generic 
queue with the PRINT/NOTIFY or SUBMIT/NOTIFY command, the notification 
message displays the name of the execution queue on which the job completes. 


2.1.9 SET DEVICE/SERVED Command 

V6.1 The DCL command SET DEVICE/SERVED cannot be used under the following 

conditions: 

• In service of a Phase II shadow set virtual unit 

• On devices that are already mounted 

• On system disks 

• On quorum disks 


2.1.10 SET PROCESS/NOAUTO_UNSHELVE Command 



V6.1 


The command SET PROCESS/NOAUTO_UNSHELVE as implemented in Version 
6.1 does not support operations across the cluster. It can be issued only for a 
process on the same node, including as the default case, the process from which 
the command is issued. 


The /IDENTIFICATION=pid qualifier is supported, but only when the target 
process is on the same node as the process where the command is issued. 


2.1.11 SET PROCESS/SUSPEND=KERNEL/ID= Command in a Cluster 
Environment — Incorrect Behavior 

VI.5 When you issue the SET PROCESS/SUSPEND=KERNEL/ID= command in a 

cluster environment, the KERNEL keyword is ignored if the target process 
and the current process reside on different cluster nodes. As a result, process 
suspension is handled as if you had specified the SUPERVISOR keyword (the 
default). 

This is caused by a problem with the $SUSPND system service, as discussed in 
Section 5.33.5. Digital expects to fix this problem in a future version of OpenVMS 
AXP. 


2.1.12 SET TERMINAL Command Enhancements 

V6.1 The SET TERMINAL command has been enhanced as follows: 

• When the /PAGE=rc qualifier is specified to set the terminal page length and 
the DEC_CRT4 characteristic is set, the SET TERMINAL command now 
sends the appropriate escape sequence to change the number of lines per 
screen. 
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• When the /INQUIRE qualifier is specified and the DEC_CRT characteristic is 
set, the SET TERMINAL command now reads the current screen size from 
the terminal and sets the corresponding page length and page width values 
appropriately. With this enhancement, DECwindows DECterm windows are 
no longer resized by SET TERMINAL/INQUIRE. 

If you specify /INQUIRE=OLD, you get behavior compatible with previous 
versions of OpenVMS. 

2.1.12.1 Restrictions 

V6.1 The enhancements to the SET TERMINAL/INQUIRE command work correctly on 

Digital supplied VT100 and later terminals. Some personal computer terminal 
emulators may not work correctly, because they do not correctly emulate all 
VT100 escape sequences. If you experience problems with these terminal 
emulators, Digital recommends that you contact your terminal emulator supplier. 

2.1.13 SHOW CPU Command Enhancement 

V6.1 The SHOW CPU command, including its related qualifiers, no longer requires 

CMKRNL privilege. In addition, it can be issued on single-CPU systems. 

2.2 DECTPU and EVE Version 3.1 Notes 

On AXP systems, the default editor is EVE instead of EDT. See Section 2.1.3 for 
information about this change in default editors. 

2.2.1 DECwindows Motif for OpenVMS AXP Operations from EVE in a 
DECterm Emulator 

VI.0 When EVE is used in a DECterm emulator, the mouse buttons are handled and 

processed by the underlying TPU code. This allows you to define the mouse 
buttons and bind TPU code to them. If you want to perform normal DECwindows 
Motif for OpenVMS AXP cut and paste operations from the DECterm emulator in 
which EVE is executing, you must turn off TPU’s mouse support. The following 
command, when used from within EVE, allows normal DECwindows Motif for 
OpenVMS AXP cut and paste operations to occur: 

Command: tpu set (mouse,off) 

This command can be entered interactively or added to an EVE initialization file. 

If you want to switch between TPU mouse support and DECwindows Motif for 
OpenVMS AXP cut and paste operations, add the following two procedures to a 
TPU command file: 

procedure eve_mouse_off; 
set (mouse,off); 
endprocedure; 
procedure eve_mouse_on; 
set (mouse,on); 
endprocedure; 

After the two commands have been compiled, you can then enter the command 
Command: Mouse off or Command: Mouse on to toggle between TPU and 
DECwindows Motif for OpenVMS AXP mouse support. 

See the OpenVMS User's Manual for more information on how to add new EVE 
commands and define the mouse buttons. 
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2.2.2 Motif Widget Context Help Built-In 

VI.0 The following built-in enters the Motif context-sensitive help mode: 

SET (WIDGET_CONTEXT_HELP, widget_variable, {on|1|off|0}) 

The mouse pointer changes to a question mark, and DECTPU waits for you to 
select a widget by clicking on MB1. DECTPU then executes the help callback of 
the selected widget (or of its parent if the selected widget has no help callback). 
The widget_variable is the widget within which the modal help interaction will 
occur, usually the top-level widget returned from the GET_INFO (SCREEN, 
“widget”) built-in. The last parameter confines the question mark pointer to the 
specified widget if ON or 1, and does not confine the pointer if OFF or 0. 

_ Note _ 

This built-in is disabled due to a problem in the Motif toolkit. 


2.2.3 Translated Images Using the TPU Callable Interface 

V6.1 Translated images that used the TPU callable interface could create an access 

violation if they specified callback routines when initializing TPU. 

This problem has been fixed. 

2.3 Sort/Merge Utility 

VI.5 The Sort/Merge utility (SORT/MERGE) runs as a native AXP image. For Version 

1.5, common data dictionary support is included. CDD/Repository is available on 
OpenVMS AXP. All user-visible functions and interfaces of SORT/MERGE are 
identical to OpenVMS VAX SORT/MERGE, with the following exceptions: 

• Support for IEEE S and T floating-point data types is now available. Two 
new qualifiers, S_FLOATING and T_FLOATING, have been added for the 
/KEY qualifier to specify these data types, as shown in the following example: 

SORT /KEY=(POS:1 , S_FLOATING) INFILE.DAT OUTFILE.DAT 

The qualifier S_FLOATING specifies S_FLOATING format data in the key 
field. The qualifier T_FLOATING specifies T_FLOATING format data in the 
key field. The SIZE parameter is optional. However, if SIZE is specified, it 
must be 4 for S_FLOATING or 8 for T_FLOATING data. 

• SORT does not trap IEEE NaNs or Denormals. Instead, they are collated as 
follows: 

-NaN < -Infinity 

+NaN > +Infinity 

-Denormal < 0 but greater than any other negative number 

+Denormal > 0 but less than any other positive number 

• During the course of SORT/MERGE development, the specification file format 
changed from the VAX VMS Version 3.0 format to the current format. If you 
still have specification files that need to be converted from VAX VMS Version 
3.0 format to the current format, you must use the SRTTRN.EXE utility 

on VAX VMS Version 4.0 through Version 6.0. SRTTRN is not provided on 
OpenVMS AXP. This is a permanent restriction. 


2-7 



General User-Level Release Notes 
2.3 Sort/Merge Utility 


• The behavior for reporting an invalid digit in a decimal string input differs 
between VAX systems and AXP systems. 

On VAX systems, you receive a reserved operand fault and a message that 
the value has been converted to a valid decimal string digit. 

On AXP systems, there is no indication of an invalid decimal digit or that 
a conversion has occurred. AXP systems do not have a decimal string 
hardware instruction to generate such a fault. The decimal string arithmetic 
is emulated in software. The data is converted with a decimal string zero 
inserted for the invalid character for comparison purposes. However, the data 
in the output file remains identical to that in the input file. 

• When SORT creates an output file containing fixed-length records whose 
record lengths vary from those of the input records, the following warning 
message is issued the first time a record with a different length is written: 

%SORT-W-VAR_FIX, records may be truncated or padded in output file: 
device:[user_directory]filename,ext 

Previously, SORT issued an “invalid record size” error message for every 
input record that was truncated or padded on output. 



_3 

System Management Release Notes 


This chapter contains information that applies to system maintenance and 
management, performance management, and networking. 

For additional information about system management features and tasks, refer 
to A Comparison of System Management on OpenVMS AXP and OpenVMS VAX. 
The Comparison manual is intended for experienced system managers who need 
to learn quickly how specific management tasks differ or remain the same on 
AXP and VAX computers. 

3.1 Using Monitoring Performance History (MPH) — An Invitation 

V6.1 Digital invites you to participate in the Digital Product Performance 

Program, which monitors and verifies in-field performance of Digital systems. 
This program provides our service, manufacturing, and design engineering 
organizations with accurate information on the performance of products at 
customer sites throughout the life of our products. Digital’s goal in developing 
reliability profiles is to provide you with improved reliability in future Digital 
products. 

To ensure the high quality of its products, Digital has developed a system 
monitoring tool called Monitoring Performance History (MPH). MPH collects the 
following information: 

• Error log entries 

• Crash dump summaries 

• Configuration information 

The information is collected on a weekly basis and sent directly to a Digital 
engineering group by way of Internet or DSNlink, bypassing the Colorado 
Support Center. There will be no feedback to you from Digital based on the data. 
The information from your system, as well as information from other customers, 
is collected in a secure database that Digital uses to create reliability profiles. 
These reliability profiles will highlight areas such as meantime-between-crashes 
(MTBCr) and meantime-between-system-interruptions (MTBSi). 

This is a voluntary program that costs you nothing and requires no special 
maintenance agreement with Digital, unless you are going to use DSNlink as 
your transport protocol. If you agree to participate in the program, you will find 
the MPH kit and installation manual in the directory [MPH] of the OpenVMS 
Version 6.1 CD-ROM media. 

MPH requires only 300 blocks of disk space for both the program and the data it 
collects. The program will not affect or degrade your system’s performance. 
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You install MPH using VMSINSTAL. The installation manual is located in the 
MPH kit and can be extracted in either text form or PostScript form. 

• To extract the installation manual in text form, enter the following command: 

$ BACKUP/SELECT=MPH_ALPHA_MERGE_INSTALL_GUIDE.TXT MPH_V_MERG030.A/SAVE [].TXT 

• To extract the information in PostScript form, enter the following command: 

$ BACKUP/SELECT=MPH_ALPHA_MERGE_INSTALL_GUIDE.PS MPH_V_MERG030.A/SAVE [].PS 

Additional information about MPH is available in a STARs article in text form on 
the kit. To extract the STARs article, enter the following command: 

$ BACKUP/SELECT=STARS.TXT MPH_V_MERGO30.A/SAVE 

MPH can be stopped on your systems at any time by entering the following 
command: 

$ @SYS$MANAGER:MPH$SHUTDOWN.COM 

MPH can be deinstalled at any time by entering the following command: 

$ @SYS$MANAGER:MPH$DEINSTAL.COM 

Digital looks forward to your participation in this mutually beneficial program. 
Thank you for your cooperation. 

3.2 AUTOGEN Command Procedure 

V6.1 AUTOGEN automatically sizes system parameters after you install or upgrade 

the operating system and after you install optional layered products. Digital 
recommends that you run AUTOGEN on a weekly basis in order to adjust your 
system parameters according to your system’s work load. 

See the OpenVMS AXP Version 6.1 Upgrade and Installation Manual for 
information about running AUTOGEN after installing the operating system. See 
A Comparison of System Management on OpenVMS AXP and OpenVMS VAX and 
the OpenVMS System Manager's Manual for additional information about using 
AUTOGEN. 

3.3 Backup Utility 

VI.5 The Backup utility (BACKUP) on AXP systems now supports hardware data 

compaction for SCSI tape drives that provide this capability. Use the BACKUP 
command qualifier /MEDIA_FORMAT=COMPACTION for these devices. 

3.3.1 Change in Processing ALIAS Directory Trees 

V6.1 In previous versions of OpenVMS, when an /IMAGE or /FAST save of a disk 

was done, ALIAS directory trees were considered for processing even though 
the primary file had already been saved. Also, the first attempt to process a file 
occurred even if the ALIAS directory tree was being scanned. To prevent this, 
users used the /EXCLUDE qualifier to prevent processing of ALIAS directory 
trees, for example: 

/EXCLUDE=([sys *.syscommon...]*.*;*) 

In OpenVMS VAX Version 6.1 and OpenVMS AXP Version 6.1, when an /IMAGE 
or /FAST save of a disk is done, ALIAS directory trees are not processed. Only 
the primary files that the ALIAS points to are saved. Depending on the number 
of ALIAS directory specifications there are on the disk, this may increase 
performance by reducing the number of files BACKUP checks for processing. If 
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the /FAST qualifier is used for the save operation, a message will be displayed for 
each ALIAS directory or file that is not processed. 

3.3.2 BACKUP Now Extends Index Files 

V6.1 In previous versions of the operating system, a problem occurred when you 

initialized a disk and extended the INDEXF.SYS file using the /HEADERS 
and /MAXIMUM_FILES qualifiers. During a BACKUP/IMAGE restore or copy 
operation with /NOINITIALIZE as the output-device qualifier, BACKUP ignored 
the extension that you made to the index file. BACKUP created on the target 
disk an INDEXF.SYS file that was the same size as the INDEXF.SYS file on the 
source disk. 

With OpenVMS AXP Version 6.1, BACKUP preserves the INDEXF.SYS file of 
the target disk if it is large enough to accommodate the number of files copied 
from the source disk. If the INDEXF.SYS file is too small, BACKUP extends the 
INDEXF.SYS file to the optimal size and displays a message. 

3.3.3 BACKUP/VERIFY Problem Fixed 

V6.1 With previous versions of the OpenVMS operating system, BACKUP did 

not perform verification on the output files in a disk-to-disk copy operation. 

The BACKUP/VERIFY command displayed a message indicating that it was 
performing verification on the output files, but actually it was not. 

OpenVMS AXP Version 6.1 corrects this problem by adding a second file 
verification scanning pass to compare the input and output files. 

_ Note _ 

BACKUP/LOG displays messages as files are successfully saved or 
verified. Because BACKUP displays the messages in the order that these 
actions occur, the sequence of the messages may be different from that of 
previous versions of OpenVMS BACKUP. 


3.3.4 BACKUP/EXACT ACCVIO Problem Fixed 

V6.1 In previous versions of the OpenVMS operating system, a BACKUP command 

with all of the following characteristics caused an access violation (ACCVIO): 

• The command specified the /EXACT_ORDER qualifier. 

• The command did not specify magnetic tape labels (using the /LABEL 
qualifier). 

• The command used more than 20 magnetic tape volumes in a single BACKUP 
operation. 

OpenVMS AXP Version 6.1 corrects this problem. 

3.3.5 BACKUP/LIST Problem Fixed 

V6.1 In previous versions of the OpenVMS operating system, the BACKUP/LIST 

command displayed preallocated files as using zero blocks of disk space. Pre¬ 
allocated files have a zero end-of-file block (EFBLK), but their allocated size 
is greater than zero. The DIRECTORY/SIZE=ALL and DIRECTORY/FULL 
commands correctly display the same number of blocks used as allocated. 

OpenVMS AXP Version 6.1 corrects this problem. The BACKUP/LIST command 
now displays the same number of blocks used as allocated for preallocated files. 
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3.3.6 

3.3.6.1 

V6.1 


3.3.6.2 

V6.1 


3.3.6.3 

V6.1 


3.3.7 

V6.1 


Changes to BACKUP Input File Processing 

The release notes in this section describe fixes to BACKUP input file processing. 

Relative File Version Support 

With previous versions of the OpenVMS operating system, BACKUP did not save 
input files that were specified by using relative file versions. For example: 

$ BACKUP A.A;-l,A.A;0,A.A;-5 SAVE.BCK/SAVE 

OpenVMS AXP Version 6.1 corrects this problem. 

_ Note _ 

BACKUP processes the relative version -0 as 0, selecting the most recent 
version of the file for processing. Digital expects to correct this problem in 
a future release. 


Rooted Directory Specification Support 

With previous versions of the OpenVMS operating system, BACKUP did not save 
input files that were specified using a rooted directory specification. For example: 

$ BACKUP DEV:[DIR.][SUBDIR]*.*;* SAVE.BCK/SAVE 

OpenVMS AXP Version 6.1 corrects this problem. 

BACKUP Handling of Forced Errors Improved 

With previous versions of the OpenVMS operating system, files that received 
Forced Error read errors during an OpenVMS BACKUP image save operation 
would be included in a save set twice, once in the original directory and once as 
part of the lost files pass. This wasted save-set space and could cause a restore 
operation to fail due to restoring more files and disk blocks than was originally 
contained on the source disk. 

Additionally, the restore operation did not indicate that an error occurred during 
the save operation and that the restored file’s data may be questionable. 

OpenVMS AXP Version 6.1 corrects this problem. BACKUP issues the 
appropriate error messages but does not include files a second time in the save 
set as lost files. Additionally, BACKUP now issues a warning during the restore 
operation regarding any errors that occurred during the save operation. 

NOMSG Problem Corrected 

With previous versions of OpenVMS operating system, BACKUP sometimes 
displayed the NOMSG error message while trying to display a message. 

OpenVMS AXP Version 6.1 corrects this problem. 


3-4 


System Management Release Notes 
3.3 Backup Utility 


3.3.8 Backup Support for Tapes Connected to InfoServer Systems 

Previously, you could not back up and restore the system disk using tapes 
connected to an InfoServer system. With Version 6.1 of the OpenVMS AXP 
operating system, you can now perform these tasks using either of the specialized 
backup environments described in Appendix B of the OpenVMS AXP Version 6.1 
Upgrade and Installation Manual. 

Tape Handling Problem Corrected 

With previous versions of the OpenVMS operating system, when a BACKUP save 
operation to tape failed with a PROCINDEX error message, you could not append 
any save sets to the tape (BACKUP issued the NOTANSI error message). 

OpenVMS AXP Version 6.1 corrects this problem. 

3.3.10 Restrictions 

VI.5 The following restrictions apply to the Backup utility: 

• A BACKUP operation to mixed tape and disk save sets, as shown in the 
following command, is unsupported: 

$ BACKUP SYS$DISK:/IMAGE dkaO:FOO,MKAO:/SAVE/REW 

V6.1 On an OpenVMS system disk, the file [SYSx]SYSCOMMON.DIR is an alias 

directory of the file [000000]VMS$COMMON.DIR. This means that both 
files point to the same file header. Prior to the OpenVMS AXP Version 1.5 
operating system, during the restore operation, BACKUP did not properly 
restore the VMS$COMMON.DIR file. Although this does not affect the 
system disk, it might produce errors with DIGITAL Command Language 
(DCL) lexical functions. 

OpenVMS AXP Version 1.5 corrected this problem. However, if you restored 
image backups created with a previous OpenVMS version, the problem 
recurred. 

The symptoms of the problem are different depending on which version of the 
operating system you are using. If you upgraded from OpenVMS AXP Version 
1.5 to OpenVMS AXP Version 6.1, it is unlikely that your system disk has 
this problem. However, you should confirm this and correct the problem if 
necessary. 

Upgrading from OpenVMS AXP Version 1.5 Systems 

If you upgraded to OpenVMS AXP Version 6.1 from OpenVMS AXP Version 
1.5 without following the procedure in Fixing the System Disk, your system 
disk could be affected by this problem. 


3.3.9 

V6.1 
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To determine if your system disk has this problem, enter a BACKUP/LIST 
command to display save-set information about the files contained in the 
VMS$COMMON directory. For example: 


[ 000000 JVOLSET.SYS;1 

0 

24-SEP-1992 

19:31 

[ ]000000.DIR;1 

1 

24-SEP-1992 

19:31 

[]SYSCOMMON.DIR;1 

2 

24-SEP-1992 

19:31 

[]SYSLIB.DIR;1 

18 

24-SEP-1992 

19:31 

[]SYSTEST.DIR;1 

1 

24-SEP-1992 

19:31 

[ JSYSMAINT.DIR;1 

1 

24-SEP-1992 

19:31 

[]SYSMGR.DIR;1 

6 

24-SEP-1992 

19:31 

[]SYSHLP.DIR;1 

6 

24-SEP-1992 

19:31 

[]EXAMPLES.DIR;1 

1 

24-SEP-1992 

19:31 

[ ]SYSUPD.DIR;1 

4 

24-SEP-1992 

19:31 

[ JSYSMSG.DIR;1 

3 

24-SEP-1992 

19:31 


[]SECURITY AUDIT.AUDIT 

2 

3-AUG-1993 

15:23 

[]SECURITY AUDIT.AUDIT 

11 

3-AUG-1993 

15:23 

[ ]BACKUP.EXE;33 

273 

4-AUG-1993 

09:37 

[JSTABACKUP.EXE;9 

486 

4-AUG-1993 

09:38 


If the display lists the files in the VMS$COMMON directory as lost files (files 
with an empty directory specification as shown in the previous example), your 
system disk is affected by this problem. To correct this problem, follow the 
procedure in Fixing the System Disk. 

Fixing the System Disk 

To restore VMS$COMMON to its proper state, enter the following commands: 
$ SET DEFAULT DISK:[000000] 

$ SET FILE/ENTER=SYSCOMMON.DIR VMS$COMMON.DIR 
$ SET FILE/REMOVE VMS$COMMON.DIR; 

$ RENAME SYSCOMMON.DIR VMS$COMMON.DIR 

_ Note _ 

Restoring image backups created with a previous VMS version will cause 
the problem to recur. 


• By using the /COMPARE and /IMAGE qualifiers, you can instruct BACKUP 
to perform an image compare operation. The image compare operation 
compares the files on one disk to the files on a second disk using the file 
identifications (FIDs) of the files. 

An image compare operation sometimes does not work correctly when you 
create two disks with identical files by incrementally backing up and restoring 
the files from one disk to the other disk. This is because BACKUP does not 
ensure that the incrementally restored files have the same FIDs as the 
incrementally saved files. This is true regardless of whether the /OVERLAY, 
/NEW_VERSION, or /REPLACE qualifiers were used in the restore command. 
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3.4 Backing Up and Restoring the System Disk 

V6.1 A menu-driven command procedure that starts automatically when you boot 

the OpenVMS AXP distribution compact disc allows you to perform backup and 
restore operations on the system disk more easily. For more detailed information 
about using the menu to perform these operations, see the OpenVMS AXP Version 
6.1 Upgrade and Installation Manual and the OpenVMS System Manager's 
Manual. 


_ Note _ 

Digital recommends that you use the menu-driven command procedure 
included on the OpenVMS AXP distribution compact disc to perform 
backup and restore operations on the system disk. 

However, in instances where you do not have access to the compact 
disc, Digital provides an alternate procedure that allows you to install a 
minimum version of the operating system on a separate data disk. After 
booting from that data disk, you can then perform backup and restore 
operations on your system disk. This alternate method is described in the 
OpenVMS AXP Version 6.1 Upgrade and Installation Manual. 


3.5 Batch and Print Queueing System 

The following notes apply to the new batch and print queueing system introduced 
in OpenVMS AXP Version 1.5. 

3.5.1 PRINT/DELETE Command Requirement 

VI.5 Before OpenVMS AXP Version 1.5, the queue manager allowed users to specify 

the PRINT/DELETE command for a file residing on a disk that was not mounted 
clusterwide, as long as the queue specified in the command was assigned to a 
node with access to the file being printed. 

As of Version 1.5, the new clusterwide queue manager process must have access 
to the file specified with the PRINT/DELETE command. Otherwise, the file is 
printed but not deleted. 

This problem will be addressed in a future release of the OpenVMS AXP 
operating system. Until then, you can ensure that the PRINT/DELETE 
command deletes the specified files by mounting the disks on which the files 
reside clusterwide. To mount a disk clusterwide, use the /CLUSTER qualifier 
with the MOUNT command. 

However, if your operating environment does not allow you to mount a disk 
clusterwide, you can resolve this problem by running the queue manager process 
on a node that has access to the disk. You can specify the node on which the 
queue manager process runs by specifying the /ON =node-list qualifier with the 
START/QUEUE/MANAGER command. For more information on this qualifier, 
see the OpenVMS DCL Dictionary. 

The information in this note also applies to the SUBMIT/DELETE command. 
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3.5.2 STOP/QUEUE/RESET Command — Problem 

VI.5 Under certain conditions, executing the START/QUEUE command within 1 

minute of executing the STOP/QUEUE/RESET command can cause a symbiont 
process and all queues serviced by the symbiont to stop. When this happens, the 
following messages are written to the operator log: 

%%%%%%%%%%% OPCOM 20-JAN-1993 09:53:29.20 %%%%%%%%%%% 

Message from user QUEUE_MANAGE on VMSPRT 
%QMAN-E-SYMDEL, unexpected symbiont process termination 

%%%%%%%%%%% OPCOM 20-JAN-1993 09:53:29.21 %%%%%%%%%%% 

Message from user QUEUE_MANAGE on VMSPRT 

-PSM-F-BADLOGIC, internal logic error detected at PC 00000000 

To avoid this problem, if you enter a STOP/QUEUE/RESET command, wait at 
least 1 minute before entering the START/QUEUE command. 

3.6 New Caching Default 

V6.1 By default, when you mount a disk, write-back caching is now enabled. Only 

PATHWORKS servers can use write-back caching. All other applications use 
write-through caching. 

3.7 DECamds Version 6.1 (Digital Availability Manager for 
Distributed Systems) 

V6.1 The DECamds kit is now included with the base operating system kit as a 

separately installable save set. The DECamds kits install and work on any 
OpenVMS AXP system. Before installing DECamds, DECwindows Motif for 
OpenVMS Version 1.1 or higher must be installed. You can use DECamds with 
the VAXcluster license. If you own the DECamds VI.0 license, this license will 
also continue to be valid. 

DECamds is a real-time monitoring, investigation, diagnostic, and software 
correction tool to assist system managers and system integrators in improving 
system availability on OpenVMS systems. DECamds collects and analyzes 
system-level data simultaneously from multiple nodes, directing all output to a 
centralized DECwindows Motif for OpenVMS display. Based on collected data, 
DECamds analyzes and directs corrective actions for exhausted resources and 
problems with gaining access to system resources. 

For information on how to install and use DECamds, refer to the DECamds User's 
Guide , which is included in the Advanced System Management documentation 
kit. 


_ Note _ 

The DECamds console can be installed only on an OpenVMS VAX system. 
Therefore, if you have only OpenVMS AXP systems, do not install this 
product. For information on DECamds, see the DECamds User's Guide. 
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3.8 DECdtm Services and DECnet/OSI (DECnet Phase V) 

V6.1 If you install DECnet/OSI on OpenVMS AXP Version 6.1, you cannot use DECdtm 

services. 

Unlike OpenVMS VAX Version 6.1, OpenVMS AXP Version 6.1 does not support 
full names. DECdtm services need full name support to run over DECnet/OSI. 

You can continue to use DECdtm services on OpenVMS AXP Version 6.1 if you do 
not have DECnet/OSI installed. 

3.9 DECnet for OpenVMS AXP (DECnet Phase IV) 

The following sections describe new support and restrictions that apply to DECnet 
for OpenVMS AXP (DECnet Phase IV). For information on using DECnet/OSI 
(DECnet Phase V) on AXP systems, see the documentation for DECnet/OSI. 

3.9.1 Cluster Alias Support Available 

VI.5 DECnet cluster alias routing support is available in Version 1.5. Note, however, 

that the Product Authorization Key (PAK) name that enables DECnet for 
OpenVMS AXP cluster alias routing support (DVNETEXT) is different from 
the PAK name that enables OpenVMS VAX cluster alias routing support 
(DVNETRTG). The functions that are supported with the DVNETEXT (extended 
function) license differ from the VAX DVNETRTG license. DVNETEXT is 
supported only to enable Level 1 routing on AXP nodes acting as routers for a 
cluster alias. 

In a mixed-architecture VMScluster environment, the router for the cluster alias 
can be either an AXP system or a VAX system. 

For additional information, see the chapter on networking management tasks in 
A Comparison of System Management on OpenVMS AXP and OpenVMS VAX. 

3.9.2 Restrictions 

VI.5 The following restrictions apply to DECnet for OpenVMS AXP: 

• You must start the LAT software after you start DECnet. If you start DECnet 
after you start LAT, all existing LAT connections are terminated, and you 
might be unable to reconnect using LAT. This restriction only applies to 
Ethernet ports that will be running both LAT and DECnet (it does not apply 
to FDDI). 

• Level 1 routing is available but is supported only on DECnet for OpenVMS 
AXP nodes acting as routers for a cluster alias. Routing between multiple 
circuits is not supported. Level 2 routing is not supported on DECnet for 
OpenVMS AXP nodes. 

• Some line types are unsupported. 

DECnet for OpenVMS AXP nodes can connect to a DECnet network only via 
Ethernet lines or FDDI lines. DECnet communication over Cl lines is not 
supported. There also is no support for DDCMP lines. 

Because DDCMP lines are unsupported, the DCL command SET TERMINAL 
/PROTOCOL=DDCMP /SWITCH=DECNET also is unsupported on AXP 
systems. 
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3.10 DECwindows — Increased VIRTUALPAGECNT Requirements 

V6.1 In Version 6.1, a change was made to the DECwindows display server 

that dramatically increased the required value for the system parameter 
VIRTUALPAGECNT. An appropriate value for this parameter will automatically 
be set at installation time by AUTOGEN. The value to which this parameter 
is set is dependent on the particular configuration—the type and number of 
graphics adapters on the system. You will not be able to set VIRTUALPAGECNT 
to any value below the minimum required for your graphics configuration. 

If you change the type or number of graphics adapters included in your 
workstation, rerun AUTOGEN so that the VIRTUALPAGECNT parameter 
is reset accordingly. 

Since the VIRTUALPAGECNT setting is used to support hardware address space 
rather than system memory, the value of VIRTUALPAGECNT set by AUTOGEN 
should not be used to gauge the size of your page file. 

3.11 Help Message Utility (MSGHLP) Restriction 

VI.0 Currently, user-supplied comments or additions to Digital supplied 

.MSGHLP$DATA files will not be preserved through the next upgrade. However, 
your own .MSGHLP$DATA files are not affected by future releases. 

Note that you can reuse .MSGHLP files to insert your own messages into future 
Digital supplied database files. Depending on the content of future databases, 
you may also be able to reuse some .MSGHLP files to insert comments to existing 
messages. 

3.12 InfoServer Notes 

The following notes pertain to the InfoServer. 

Installing OpenVMS from the InfoServer System on a DEC 4000 System 

If you use the InfoServer system to install the OpenVMS AXP Version 6.1 
operating system on a DEC 4000 system using firmware prior to Version 3.2, add 
the following item to the BOOT command: 

-START 0 

The following example shows a complete BOOT command: 

»> BOOT -FL 0,0 -FI APB_061 -START 0 lan-device-name 
This problem is fixed for firmware versions 3.2 or later. 

3.12.2 Updating InfoServer Software from ConDIST 

V6.1 You can use Disc 1 of Digital’s Consolidated Software Distribution (ConDIST) 

to update InfoServer software. To perform an update operation, log in to the 
InfoServer system and follow these steps: 

1. Insert the disc in a compact disc drive attached to the InfoServer system. 

2. At the InfoServer> prompt, enter a command in the following format, where 
n is the drive number: 

On the InfoServer 100 or InfoServer 150 system: 

InfoServer> UPDATE SYSTEM DKn: 


3.12.1 

V6.1 
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3.12.3 

V6.1 

3.12.4 

V6.1 

3.12.5 

V6.1 


3.12.6 

V6.1 


On the InfoServer 1000 system: 

InfoServer> UPDATE SYSTEM DKn: FLASH 

This command moves the InfoServer software to the internal read/write 
device. The next time you boot the InfoServer system, it runs the updated 
software. 

Note that because you cannot boot the server from the ConDIST disc, you should 
retain the InfoServer Software compact disc that shipped with your InfoServer 
Software kit. 

Accessing ISO 9660 Compact Discs from an InfoServer System 

To make ISO 9660 compact discs available to OpenVMS client systems from an 
InfoServer system, the InfoServer manager must create services in the ODS_2 
service class for these discs. 

Minimum Version of InfoServer Kernel Required 

In order to install OpenVMS AXP from the InfoServer, the InfoServer must be 
running InfoServer Kernel Version 2.2 or greater. 

InfoServer Booting from DEC 7000 and DEC 10000 Systems — 
Restriction 

InfoServer booting for operating system upgrades or installations on DEC 7000 
and DEC 10000 systems is not supported with Version 3.1 or greater of the 
InfoServer kernel, if your console firmware is Version 3.0 or earlier. 

If this is your current configuration, Digital recommends that you upgrade your 
console firmware. 

Digital will address this restriction in the future. 

Losing Connection to the InfoServer 

If you booted the OpenVMS AXP Version 6.1 kit from an InfoServer, you might 
lose your connection to the InfoServer due to network hardware or software 
problems, or an overloaded network. 

If you do lose the connection to the InfoServer, the system will hang. To remedy 
the situation, try pressing Ctrl/Y. If Ctrl/Y fails to return you to the menu (which 
displays options for installing or upgrading, entering a DCL environment, or 
shutting down), then you have lost the connection to the distribution compact disc 
connected to the InfoServer. 

To recover from this situation, do the following: 

• If you had previously chosen the INITIALIZE option during the installation 
operation, reboot and perform the installation again. 

• If you had previously chosen the PRESERVE option, first reboot and restore 
the backup of your target disk. Then perform the installation or upgrade 
again. 
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INITIALIZE — Recovery of Badly Initialized Root Directory 

In the Software Developer Toolkit version of OpenVMS AXP Version 6.1, 
INITIALIZE did not initialize the root directory of a volume, 000000.dir correctly. 
This bad initialization could cause the directory entry for this file to be deleted, 
and also prevent you from being able to set ACLs on 000000.dir. 

To tell whether you have a disk that has suffered from this, use the ANALYZE 
/DISK_STRUCTURE command on the disk. A new warning message has been 
added to flag this condition: 

%ANALDISK-W-BADINITD_MFD, Root directory 000000.DIR;1 file header 
incorrectly initialized, RVN 1 

Use the ANALYZE/DISK_STRUCTURE/REPAIR command to repair this bad 
initialization. 

If the directory entry for 000000.dir has been deleted, then use ANALYZE/DISK_ 
STRUCTURE/REPAIR to repair this as well. The warning you will receive from 
ANALYZE/DISK_STRUCTURE if this directory entry has been deleted is: 

%ANALDISK-W-LOSTHEADER, file (4,4,1) 000000.DIR;1 not found in a directory 

3.14 Installation and Upgrade 

The following notes contain information on the installation or upgrade of 
OpenVMS AXP. 

3.14.1 DECnet/OSI 

The following notes pertain to the DECnet/OSI software. 

3.14.1.1 DECnet/OSI Field-Test Version Must Be Removed 

V6.1 If you have installed Version T2.1-FT3 of DECnet/OSI (also called DECnet Phase 

V), you must remove it before upgrading to OpenVMS Version 6.1. The OpenVMS 
installation procedure will remind you of this if you do not remove DECnet/OSI. 

During the removal of DECnet/OSI, you will see four PCSI-E-RESGEN errors. 
The POLYCENTER Software Installation utility will recommend terminating for 
each of these errors. However, the DECnet/OSI removal procedures will resolve 
these problems. Therefore, you should answer NO when you are asked “Do you 
want to terminate?” after each of these four errors. (Note that the default answer 
is YES; you must type NO.) 

The removal dialog for DECnet/OSI may look like the following: 

$ product remove decnet_osi 

The following product has been selected: 

DEC AXPVMS DECNET_OSI T2.1-FT3 

Do you want to continue? [YES] 

The following product will be removed: 

DEC AXPVMS DECNET_OSI T2.1-FT3 

%PCSI-E-RESGEN, the file [SYS$LDR]NET$CSMACD.EXE provided by 
DEC AXPVMS DECNET/OSI T2.1-FT3 will remain installed; 
replacement material unavailable 

Terminating is strongly recommended. Do you want to terminate? [YES] NO 

%PCSI-E-RESGEN, the file [SYS$LDR]NET$FDDI.EXE provided by 
DEC AXPVMS DECNET/OSI T2.1-FT3 will remain installed; 
replacement material unavailable 

Terminating is strongly recommended. Do you want to terminate? [YES] NO 


3.13 
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%PCSI-E-RESGEN, the file [SYS$LDR]SYS$NETWORK_SERVICES.EXE provided by 
DEC AXPVMS DECNET_OSI T2.1-FT3 will remain installed; 
replacement material unavailable 

Terminating is strongly recommended. Do you want to terminate? [YES] NO 

%PCSI-E-RESGEN, the file [SYSEXEJNCP.EXE provided by 
DEC AXPVMS DECNET_OSI T2.1-FT3 will remain installed; 
replacement material unavailable 

Terminating is strongly recommended. Do you want to terminate? [YES] NO 

3.14.1.2 Messages While Upgrading from OpenVMS AXP Version 1.5 

V6.1 If you are upgrading from OpenVMS Version 1.5 and you have DECnet/OSI 

(DECnet Phase V) installed, you will see the following warnings when you boot 
your upgraded Version 6.1 system: 

%SYSINIT-W- system image LES$LES_V30 load failed 

%SYSINIT-E-error loading <SYS$LDR>LES$LES_V30.EXE status = 00000910 

%SYSINIT-W- system image NET$MESSAGE load failed 

%SYSINIT-E-error loading <SYS$LDR>NET$MESSAGE.EXE status = 00000910 

These messages will appear during every boot until DECnet/OSI for OpenVMS 
AXP is again installed. If do not wish to install DECnet/OSI, you can eliminate 
these messages by executing the following commands: 

$ MCR SYSMAN SYS_LOADABLE REMOVE DECNET NET$MESSAGE 
$ MCR SYSMAN SYS_LOADABLE REMOVE DECNET LES$LES_V30 
$ @SYS$UPDATE:VMS$SYSTEM_IMAGES.COM 

In a VMScluster environment with multiple system disks, these commands must 
be executed once for each system disk. For each system disk, execute these 
commands on a node that boots from that disk. 

3.14.2 Removing the OpenVMS AXP Operating System 

V6.1 Although the use of the PRODUCT REMOVE command is not officially supported 

in OpenVMS AXP Version 6.1 for the removal of the OpenVMS operating system, 
you can use the PRODUCT REMOVE command to remove most of the OpenVMS 
AXP operating system from a system disk without affecting user files on the disk. 

Follow these steps to remove OpenVMS AXP: 

1. If your system disk has multiple system-specific roots, boot the system and 
execute SYS$MANAGER:CLUSTER_CONFIG to remove all roots except the 
one from which you are booted. 

2. Shut down and boot from the distribution CD or from a system disk other 
than the one from which OpenVMS AXP is being removed. Execute the 
following DCL commands; substitute the device name of the disk from which 
OpenVMS AXP is being removed for <target-disk>, and the root number that 
you did not remove in step 1 for SYSx. 

$ DEFINE/NOLOG PCSI$SYSDEVICE <target-disk> 

$ DEFINE/NOLOG PCSI$DESTINATION <target-disk>:[VMS$COMMON] 

$ DEFINE/NOLOG PCSI$DSPECIFIC <target-disk>:[SYSx.] 

$ PRODUCT REMOVE VMS /REMOTE 

If OpenVMS AXP is not running from the distribution CD, you will need to be 
logged in to a privileged account. 
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3.14.3 

V6.1 


3.14.4 

V6.1 


3. After the remove operation completes, review the target disk to determine 
if you want to delete the following files, which the PRODUCT REMOVE 
command cannot remove. 

• In <target-disk>:[SYS*.SYSEXE], where * is 0 or the hexadecimal number 
of any additional VMScluster roots on the target disk: 

ALPHAVMSSYS.PAR; 1 
MODPARAMS.DAT; 1 
PAGEFILE.SYS;1 
SWAPFILE.SYS;1 

• In <target-disk>:[VMS$COMMON.SYSEXE]: 

LMF$LICENSE.LDB;1 
PCSI$FILE_SYSTEM.PCSI$DATABASE;1 
PCSI$PROCESSOR.PCSI$DATABASE;l 
PCSI$ROOT.PCSI$DATABASE; 1 
RIGHTSLIST.DAT;! 


_ Note _ 

Do not remove the *.PCSI$DATABASE files if you have layered products 
installed on this disk, or if you want to maintain a history of software 
installation on this disk. 


4. Review the target disk for the directory structures [VMS$COMMON...] and 
[SYSx...], which will remain after removing OpenVMS AXP. You may want to 
remove these directories. 

Spurious Message During Booting 

You may see the following message on some systems during booting. Do not be 
alarmed; contrary to the message, the installation has completed correctly. 

%INSTALL-I-NONRES, installed image non-resident with other specified 
options 

-INSTALL-E-NOGHREG, insufficient memory in the code or data granularity hint 
region 

You can either ignore this message or run AUTOGEN to eliminate the error 
message. 

For more information on the /RESIDENT qualifier, see the OpenVMS System 
Management Utilities Reference Manual. For more information on installing 
resident images, see the OpenVMS Linker Utility Manual. 

Error Messages During Installation 

When you are installing or upgrading to OpenVMS Version 6.1, you may get a 
warning banner with error messages similar to the following: 
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************************************************************ 

* * 

* WARNING * 

* * 

* One or more errors were encountered during execution * 

* of one or more of the DCL command procedures in the KIT.* 

* * 

* If you continue, the target system may not be usable. * 

* * 

* Digital recommends that you correct the condition that * 

* caused the error and repeat the installation. * 

* * 
************************************************************ 

Press Return to view error messages... 

<error messages> 

If you run another installation after correcting these error conditions, you will 
see one or more %SYSTEM-F-NOLOGNAM errors after the prompt for detailed 
descriptions, for example: 

Do you always want detailed descriptions? (Yes/No) [No] 

%SYSTEM-F-NOLOGNAM, no logical name match 

Messages for the errors from the previous installations will be repeated during 
the subsequent installations, preceding any additional errors. To avoid this 
problem, reboot your kit CD-ROM after receiving these error messages before 
attempting another installation. 


3.14.5 Failure to Install Images Resident 

V6.1 The following error messages may be displayed when booting a node into a 

VMScluster system: 

waiting to form or join a VMScluster system 

%VMScluster-I-LOADSECDB, loading the cluster security database 
%CNXMAN, Proposing formation of a VMScluster 
%CNXMAN, Now a VMScluster member — system VMSTS5 
%CNXMAN, Completing VMScluster state transition 
%MSCPLOAD-I-CONFIGSCAN, enabled automatic disk serving 

$! Copyright (c) 1993 Digital Equipment Corporation. All rights reserved. 
%STDRV-I-STARTUP, VMS startup begun at 5-AUG-1993 14:04:00.11 
%INSTALL-E-RESFAIL, failed to install image with /RESIDENT qualifier 
-INSTALL-E-NOGHREG, insufficient memory in the code granularity hint region 

These messages indicate that not all images could be installed resident. This can 
result in some level of performance degradation, but is otherwise benign. 

A possible workaround is to increase the values of the GH_RSRVPGCNT system 
parameter. 

3.14.6 Security Auditing 

This section contains installation and upgrade information related to security. 

3.14.6.1 Audit Server Database Name Change 

V6.1 The security auditing server process maintains the set of auditing events that are 

enabled on the system. The audit server process stores this information in a file 
in SYS$MANAGER. In OpenVMS AXP Version 6.1, the name of this file has been 
changed from AUDIT_SERVER.DAT to VMS$AUDIT_SERVER.DAT because the 
format of the Version 6.1 file differs from earlier versions. 
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3.14.6.2 

V6.1 


V6.1 


V6.1 


3.14.7 

V6.1 


Audit Server Database Files in Mixed-Version Clusters 

As Section 3.14.6.1 describes, the name for the audit server database changes in 
Version 6.1 from AUDIT_SERVER.DAT to VMS$AUDIT_SERVER.DAT. When 
redirecting this file off the system disk, system managers doing a rolling upgrade 
must provide logicals for both AUDIT_SERVER and VMS$AUDIT_SERVER in 
SYSECURITY.COM. As before, these logical names must be defined /SYSTEM 
/EXEC. 

Audit Log Files in Mixed-Version Clusters 

The Audit Analysis utility (ANALYZE/AUDIT) running on Version 1 .n systems 
is unable to process Version 6.1 audit log files. You must use Version 6.1 of 
ANALYZE/AUDIT to process Version 6.1 audit log files. The recommended 
procedure is to maintain separate audit log files on mixed-version clusters. 

If redirecting the audit log files, the command SET AUDIT/JOURNAL 
/DESTINATION=filespec should be issued on both a Version l.n node and on 
a Version 6.1 node. The destination filespec is stored in the audit server database 
file. By default, the files are stored in SYS$COMMON:[SYSMGR] and are called 
SECURITY_AUDIT.AUDIT$JOURNAL and SECURITY.AUDIT$JOURNAL, 
respectively. See the OpenVMS Guide to System Security for further information. 

Auditing Configuration 

Prior to Version 6.1, SET AUDIT commands in different command procedures or 
startup files established audit server settings. With Version 6.1, the audit server 
stores auditing settings in a permanent database. The settings in the database 
VMSSAUDIT_SERVER.DAT are reinstated on each system startup. 

Therefore, system managers running Version 6.1 systems can remove SET AUDIT 
commands from startup files and command procedures. After reviewing the new 
auditing system described in the OpenVMS Guide to System Security , managers 
can configure a Version 6.1 auditing system. Section 3.24.1 provides a brief 
summary of the outstanding changes. 

VMSKITBLD.COM — Incompatibility with POLYCENTER 

OpenVMS AXP Version 6.1 is installed using the POLYCENTER Software 
Installation utility. VMSKITBLD.COM has not been updated to create disks 
that are equivalent to those created by the POLYCENTER Software Installation 
utility. The only supported mechanism for installing or upgrading to OpenVMS 
Version 6.1 is to use the installation CD-ROM. 

The version ofVMSKITBLD.COM that is shipped with OpenVMS Version 6.1 
has been disabled by placing an EXIT statement after a warning about the 
problem described previously. If you choose to remove this EXIT statement, you 
will be able to use VMSKITBLD.COM to create usable system disks. However, 
system disks created by using VMSKITBLD.COM will not be able to be upgraded 
by future OpenVMS AXP upgrade procedures. In addition, layered product 
and third-party product installations that use the POLYCENTER Software 
Installation utility may not be able to be installed on system disks created by 
using VMSKITBLD.COM. 

Digital expects to provide a replacement for the functionality of 
VMSKITBLD.COM in a future version of OpenVMS AXP. 
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3.14.8 Volume Shadowing 

V6.1 Please refer to the volume shadowing documentation for information about 

Volume Shadowing for OpenVMS. 


_ Caution _ 

Do not attempt to install the volume shadowing layered product on 
OpenVMS AXP Version 6.1. The resulting system will not work. An 
OpenVMS AXP Version 1.5 system on which the volume shadowing 
layered product was installed can be upgraded to OpenVMS AXP Version 
6 . 1 . 


As part of upgrading a shadowed system disk to OpenVMS AXP Version 6.1, the 
shadow set must be dismounted. See the OpenVMS AXP Version 6.1 Upgrade 
and Installation Manual for more information. 

3.14.9 No Upgrade from OpenVMS AXP Version 1.0 

V6.1 An upgrade from OpenVMS AXP Version 1.0 is not supported and does not 

work. An upgrade from field-test versions of OpenVMS AXP Version 1.5 is not 
supported. 

3.14.10 Upgrade from Field-Test Versions of OpenVMS AXP Version 6.1 

V6.1 For OpenVMS AXP Version 6.1, the internal names used for optional features 

of OpenVMS are being changed to facilitate future maintenance by making the 
names more meaningful. This change was made between OpenVMS AXP Version 
6.1-FT4 and Version 6.1. 

If you have installed any field-test version of OpenVMS AXP Version 6.1 and you 
have selected specific options, then you must select these options again when you 
install Version 6.1. 

If you did not make specific option selections but always responded YES to the 
question “Do you want all the default values for this product?”, then you can 
answer YES to this question during the Version 6.1 upgrade, or you can answer 
NO to review or to change the default values. 

3.15 Changes to the Install Utility 

VI.5 In Version 1.0, you could use the Install utility (INSTALL) to install shareable 

images resident. Version 1.5 lets you install main images resident. Note that 
these main images must be linked with the /SECTION_BINDING qualifier before 
they can be installed resident. 

An attempt to install an image /RESIDENT may fail if the code granularity hint 
region contains insufficient memory or if the image was linked incorrectly (that 
is, linked without the /SECTION_BINDING=CODE qualifier). If the attempt fails 
for either of these reasons, INSTALL now automatically attempts to install the 
image without the /RESIDENT qualifer but with all other specified options. 

When this occurs, the Install utility displays messages, as shown in the following 
example: 

$ INSTALL 

INSTALL> CREATE/RESIDENT SYS$LIBRARY:F00.EXE 

%INSTALL-I-NONRES, installed image non-resident with other specified options 
-INSTALL-E-NOGHREG, insufficient memory in the code or data granularity hint region 
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3.16 I/O Buffer Cache Pools — Changes 

V6.1 The minimum sizes of three I/O buffer cache pools have been increased: 


Pool 

System Parameter 

Old 

Minimum 

New 

Minimum 

Directory pool 

ACP.DIRCACHE 

2 

4 

Header pool 

ACP_HDRCACHE 

3 

8 

Bitmap pool 

ACP_MAPCACHE 

1 

2 


3.17 LAT Notes 

This section contains information about LAT software. 

3.17.1 Starting LAT Software 

V1.0 OpenVMS AXP supports the LAT software when running on a suitably configured 

system. See the OpenVMS System Manager's Manual for more information about 
starting and using the LAT software. 


_ Note _ 

You must start the LAT software after you start DECnet. If you start 
DECnet after you start LAT, all existing LAT connections are terminated, 
and you might be unable to reconnect using LAT. This restriction applies 
only to Ethernet ports that will be running both LAT and DECnet (it does 
not apply to FDDI). 


Always start LAT from the SYSTEM account because this account typically has 
appropriate privileges and quotas. 

3.17.2 New Baud Rate Support for VT500 Series Terminals 

V6.1 VT500 series terminals are now supported with the following baud rates: 

• 57600 baud 

• 76800 baud 

• 115200 baud 

The only terminal controllers capable of supporting all these speeds are the 
DECserver 700 and DECserver 900 controllers. However, the DECserver 90TL 
and DECserver 90M support terminal port speeds up through 57600. When 
the DECserver communicates with the OpenVMS AXP system using the LAT 
software, a restriction allows the LAT software to report speeds only up to 57600. 

This restriction will be addressed in a future release. 

3.17.3 BYTLM Quota and LTA Devices 

V6.1 Previously, if you created an LTA device and assigned a logical name to it without 

first specifying the device number, the system consumed the process BYTLM; 
bytes would only be credited back to the creating process when the LTA device 
was deleted. If several LTA devices were created in the previously described 
manner, system startup processes would run out of BYTLM and would not finish. 
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3.17.4 

VI.5 


Beginning with Version 6.1 of the OpenVMS AXP operating system, LTDRIVER 
credits the byte count of a created LTA device back to the creating process if 
the device is going to be a permanent LTA device (for example, APPLICATION, 
DEDICATED, or LIMITED). 

Change in LAT Behavior 

After you enter the LATCP CREATE LINK /DECNET command, the following 
message may be displayed: 

%SYSTEM-F-BADPARAM, bad parameter value 

This may indicate that the SCSSYSTEMID system parameter is set to an illegal 
value. Use the following formula when setting this parameter: 

(1024 * a) + n 

In the formula, a is the DECnet area and n is the DECnet node number. 

When you use the /DECNET qualifier with the LATCP CREATE LINK command, 
be sure that the value of the SCSSYSTEMID system parameter is within the 
range of 1025 to 65535, as determined by the previous formula. The value for 
this parameter should match the results obtained by using the formula. If the 
value is outside the range of 1025 to 65535, the LAT protocol is unable to start. 

When you use the /NODECNET qualifier, the LAN device driver code decides 
what address to use. The decision is based on the following criteria: 

• If SCSSYSTEMID is set to 0 but DECnet is already running on an Ethernet 
controller, the LAN device code allows the LAT software to use the same 
address as DECnet (AA-00-04-00-xx-xx). 

• If SCSSYSTEMID is set to 0 and DECnet is not running, the 08-00-2B-xx-xx- 
xx address is used. 

• If the setting for SCSSYSTEMID is the same as the DECnet node number 
and DECnet is not running, the LAN device code forces LAT to use the 
AA-OO-04-OO-xx-xx address. 

Restriction 

If DECnet is configured on the system (or if the system is part of a cluster), 
SCSSYSTEMID may contain a nonzero value. Normally, this is not a problem 
unless the system has two or more LAN controllers connected to the same logical 
LAN. 

For example, if your system has an FDDI controller and an Ethernet controller, 
your site may be configured so that the FDDI ring attached to the FDDI controller 
and the Ethernet segment attached to the Ethernet controller are bridged by a 
10/100 LAN bridge (FDDI-to-Ethernet). In this configuration, it is impossible to 
run LAT over both controllers. 

In such a configuration, you must run LAT and DECnet over the same controller 
if SCSSYSTEMID is not 0. If you fail to do so, DECnet starts first, which in 
turn causes the LAT startup on the other controller to fail. This failure occurs 
because LAT startup tries to use the AA-00-04-00-xx-xx address (the DECnet 
LAN address); however, because DECnet is already using this address on another 
controller, the data link layer prevents the LAT startup from using that address. 
(In a single logical LAN, all data link addresses must be unique. Because both 
controllers try to use the same address, it is no longer unique.) 
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3.18 

3.18.1 

vi.o 


3.18.2 

V6.1 


Using the following command to create the LAT link also fails because the LAN 
driver tries to use the address based on SCSSYSTEMID: 

LATCP> CREATE LINK LAT$LINK_2 /NODECNET 

If SCSSYSTEMID is set to 0, configuring LAT and DECnet on different 
controllers is possible. However, in a cluster environment, SCSSYSTEMID 
cannot be set to 0. 

License Management Facility (LMF) 

This section contains information about the License Management Facility (LMF) 

PAKs on AXP and VAX Systems 

Availability Product Authorization Keys (PAKs) are available for OpenVMS AXP. 
An OpenVMS AXP PAK is identified by the keyword ALPHA in the PAK’s option 
field. 

PAKs having the ALPHA option will be loaded and used only on AXP systems. 
However, they can safely reside in a license database (LDB) shared by both VAX 
and AXP systems. 

Availability PAKs for VAX systems (availability PAKs without the ALPHA option) 
will not load on AXP systems. Only those availability PAKs containing the 
ALPHA option will load on AXP systems. 

Other PAK types, such as activity (also known as concurrent or n-user) and 
personal use (identified by the RESERVE_UNITS option), work on both VAX and 
AXP systems. 


_ Caution _ 

By default, all AXP availability PAKs look disabled to a system 
running OpenVMS VAX Version 6.0 or earlier. Never use the DELETE 
/STATUS=DISABLED command from a system running OpenVMS VAX 
Version 6.0 or earlier on an LDB that contains AXP PAKs. If you do, all 
AXP PAKs will be deleted. 


See the OpenVMS License Management Utility Manual for more information 
about using LMF. 

LICENSE Command Restrictions Removed 

In previous versions of OpenVMS, from a VAX system you could not use the 
following LICENSE commands on a PAK containing the ALPHA option: 

• COPY 

• DELETE/STATUS 

• DISABLE 

• ENABLE 

• ISSUE 

• LIST 

• MOVE 

• REGISTER 
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This restriction is lifted in OpenVMS VAX Version 6.1 and OpenVMS AXP 
Version 6.1. 

3.19 Monitor Utility 

The following notes pertain to the Monitor utility (MONITOR). 

3.19.1 MONITOR POOL Replaced 

V6.1 The DCL command MONITOR POOL that is used on OpenVMS Version 5.5 

and earlier releases is not provided on OpenVMS AXP systems or on OpenVMS 
VAX Version 6.0 and later releases. MONITOR POOL functions are replaced by 
enhanced, adaptive pool management features and two System Dump Analyzer 
(SDA) commands. 

Also refer to the OpenVMS System Manager's Manual for more information about 
the Monitor utility. 

3.19.2 MONITOR Limitation in Mixed-Version VMScluster Systems 

V6.1 The Monitor utility has been updated for OpenVMS Version 6.1 on AXP to 

communicate with OpenVMS Version 6.1 on VAX. As a result, MONITOR no 
longer communicates with older versions—Version 1.5 on AXP and Version 5.5-2 
on VAX. 

If you are running in a VMScluster system with OpenVMS AXP Version 1.5 or 
OpenVMS VAX Version 5.5-2 nodes and begin to update your VMScluster, you will 
receive the following error message when you attempt to use remote monitoring 
between updated and nonupdated nodes: 

%M0NIT0R-E-SRVMISMATCH, MONITOR server on remote node is an incompatible 
version 

You must upgrade your entire VMScluster system to Version 6.0 or Version 6.1 in 
order for MONITOR to work across all nodes in the VMScluster. 

Workaround 

You can, however, obtain MONITOR data from a remote node of a different 
version of OpenVMS by recording the data on the remote node, and then using 
the MONITOR playback feature to examine it on the local node. For details on 
using the MONITOR recording and playback features, see the OpenVMS System 
Management Utilities Reference Manual. 

3.19.3 MONITOR RMS — Items Implemented 

V6.1 Two data items under the RMS locking statistics section of the MONITOR RMS 

command are implemented in this release: 

• Bucket splits (bucket splits involving one new bucket) 

• Multibucket splits (bucket splits involving more than one new bucket) 

3.20 Mount Utility 

The following notes pertain to the Mount utility (MOUNT). 
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3.20.1 Allocation Class Required for Shadow Set Physical Devices 

V6.1 As a result of a change to the $MOUNT system service, the Mount utility will 

now enforce the device name format for shadow set member devices as defined in 
Volume Shadowing for OpenVMS. 

The device names must be specified using the format $allocation_class$ddcu 
where : 

• allocation_class must be a numeric value in the range 1 to 255. 

• dd describes the device type of the physical device (for example DI,DJ,DK, or 
DU). 

• c must be a letter from A to Z that represents the controller designation. 

• u is the unit number of the device. 

If a shadow set member device name is specified in any other format, the Mount 
utility will report an Invalid Device Name (SS$_IVDEVNAM) error. 

A logical name can be substituted for a device name provided that the logical 
name ultimately translates to a device name with the format previously 
described. 

3.20.2 New Informational Message on Mounting Tapes 

V6.1 A new informational message has been added to the MOUNT command to show 

that it is waiting for a tape to become ready in the specified tape device. The new 
informational message is: 

MOUNT-I-WAITDEVRDY Waiting for device <device-name> to become ready 

If you want to terminate the MOUNT command when this informational message 
is displayed, type Ctrl/C to stop the command. 

3.20.3 Foreign Mounted Tape: Maximum Record Size Restriction Removed 

V6.1 The maximum record size for a variable record format for a sequential file on a 

foreign mounted tape is no longer restricted to the ANSI tape maximum of 9995. 
The same maximum record sizes that apply to a sequential file on disk now apply 
to a sequential file on a foreign mounted tape. 

3.20.4 PATHWORKS Access to ISO 9660 in a WAN/LAN Environment 

VI.5 To access ISO 9660 volumes in a WAN/LAN environment, issue a 

MOUNT/SYSTEM command for the ISO 9660 volume. 

On the PC client node, assign the volume to a PC device using the appropriate 
command. For example, in an MS-DOS environment, the assignment command 
might look like the following: 

B:> USE ?: \\MYN0DE\DISK$V0LUME:[000000]%VMSUSER * 

The assignment command has the following format: 

• USE ?: commands the USE utility to assign the next available PC device. 

• \ \MYNODE indicates the OpenVMS node. 

• \DISK$VOLUME.[000000] indicates the volume and directory. 

• %VMSUSER * indicates the access control string. The asterisk in the access 
control string causes MS-DOS to prompt you for the password. 
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3.20.5 

V6.1 


3.20.6 

V6.1 


3.21 

V1.5 


Extraneous Mount Count Dismounting from Shared Mount 

If a user has entered a MOUNT/SHARE command on the system disk, a 
subsequent dismount may produce the message: 

%DISM-W-CANNOTDMT, AXP27$DKA300: cannot be dismounted 
%DISM-W-USERFILES, 1 user file open on volume 

This happens because the program DISMOUNT.EXE on the system disk is 
opened by the user in order to attempt the dismount. 

Using the MOUNT/SHARE command on disks already mounted with the 
/SYSTEM qualifier retains a lock on disk availability even if the disk is 
dismounted on a systemwide basis. This practice is not usually used for the 
system disk, but it can occur as a result of invoking a general-purpose command 
procedure that is sometimes used on the system disk and sometimes used on 
other disks. 

To prevent the message, install the DISMOUNT.EXE image. 

ISO 9660 Support in Mixed-Architecture VMScluster Systems 

On OpenVMS systems, do not specify the /CLUSTER qualifier when mounting 
ISO 9660 formatted CD-ROMs in a VMScluster system with nodes that are 
running versions of OpenVMS VAX prior to Version 6.0. If you attempt to mount 
an ISO 9660 CD-ROM on an OpenVMS node without ISO 9660 support, which 
is likely in a mixed-version environment, the operation will fail. However, the 
failure will take an excessive amount of time to complete, due to the slow access 
time for the CD-ROM media. 

Performance Degradation Due to Insufficient Swapping File 
Space 

Performance may degrade on systems using large working sets if the swapping 
file space is insufficient. 

Configurations with large process working sets that run under heavy load 
conditions must have adequate swapping file space. Processes can be swapped 
out with a working set size up to the value of WSQUOTA. The I/O that is issued 
to swap out the process can be as large as the setting for WSQUOTA and requires 
this much space in the swapping file. (WSQUOTA is a process parameter that 
you can adjust using the Authorize utility.) 

To provide adequate swapping file space, periodically run AUTOGEN with the 
FEEDBACK option. When running AUTOGEN, make sure that: 

• The system has been up long enough to have run a typical load (at least 24 
hours). 

• There is no hard-coded SWAPFILE value in the 
SYS$SYSTEM:MODPARAMS.DAT file. (A hard-coded SWAPFILE value 
prevents AUTOGEN from sizing the swapping files correctly.) 
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3,22 


3.22.1 

V6.1 


3.22.2 

V6.1 


3.22.3 

V6.1 


3.22.4 

V6.1 


AUTOGEN resizes swapping files provided there is adequate space on the 
volumes containing the swapping files. If there is insufficient space, AUTOGEN 
recommends swapping file sizes. Use swapping file sizes at least as large as those 
recommended by AUTOGEN. If the swapping file sizes need to be increased and 
insufficient free space exists on the volume containing the swapping files, perform 
one of the following steps after AUTOGEN finishes: 

• Free up space on the volume, and increase the swapping file size to at least 
the value recommended by AUTOGEN. 

• Move the swapping files to a volume with sufficient space. Make sure that 
the swapping files are at least as large as those recommended by AUTOGEN. 

• Add another swapping file. The total space in all swapping files must be at 
least as large as the total size recommended by AUTOGEN. 

POLYCENTER Software Installation Utility Restrictions 

Notes in this section pertain to problems and restrictions with using the 
POLYCENTER Software Installation utility (PCSI) to install, remove, and 
reconfigure software kits. 

DCL Scrolling Problem 

The DCL user interface cannot display one screenful of information at a time 
without it scrolling off the screen. 

Digital expects to correct this problem in a future release. 

DECWindows Motif Mode Menu Behavior 

If you use the DECWindows Motif Mode menu to select POLYCENTER Software 
Installation utility operating modes, the main window lists products that are 
available for the operation you chose. For example, if you choose the Reconfigure 
menu item, the main window lists the products available for reconfiguration. 

If no products are available for the operation you select, the main window is 
empty. 

Deleting Directories Created by POLYCENTER 

If a directory is created as a part of a product installed using POLYCENTER and 
that directory is deleted manually, a reinstallation of the same product will fail; 
POLYCENTER determines from its database that the directory should be there 
and so does not issue the command to create it. When POLYCENTER tries to 
reinstall the file, it fails. 

In general, it is a bad idea to manually delete objects that POLYCENTER has 
created; the current implementation is not robust in this particular area. 

Digital expects to correct these problems in a future release. 

Inaccurate Disk Space Reporting 

The POLYCENTER Software Installation utility estimates the amount of disk 
space required for an installation. Sometimes this number is inaccurate, and an 
installation may fail due to lack of disk space even though the utility reports that 
there is enough disk space. 

The utility also fails to check for enabled disk quotas. 

Digital expects to correct these problems in a future release. 
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3.22.5 

V6.1 


3.22.6 

V6.1 


3.22.7 

V6.1 


3.22.8 

V6.1 


Installing an Earlier Version of an Installed Product 

If you attempt to install an earlier version (one with a lower version number) of 
an installed product, the utility displays a sequence of messages. This sequence 
of messages does not have the correct defaults and by taking them, the utility 
attempts to install both versions. This causes an error similar to the following: 

%PCSI-E-FAILCONF, failed to resolve conflicting requirements for file 
[000000]DEC-VAXVMS-XYZ-V0105—l.PCSI$DESCRIPTION 

Terminating is strongly recommended. Do you want to terminate? [YES] 

The following example shows how to answer the questions to install the version 
you want: 

1. The system displays the following message: 

%PCSI-E-CONREMHV, confirm removal of higher version of DEC AXPVMS XYZ V2.0 
Do you want to take this action? [NO] 

If you want the lower version, answer YES. If you want the higher version, 
answer NO. 

2. The system displays the following message: 

Do you want to continue? [YES] 

If you want the lower version, answer YES. If you want the higher version, 
answer NO. 

Packaged Files — File Sizes 

Once you have packaged a kit with POLYCENTER into reference form, do not 
edit or change any of the individual files that have been packaged. 

The package operation creates a new Product Description File (PDF) that is used 
during the installation. In the packaged PDF, POLYCENTER writes the sizes of 
each of the files that are part of your kit. If you change or edit one of the files, 
the size of the file may differ from what is recorded in the PDF. 

Specifically, during an installation to a remote node, such as over DECnet (or any 
operation over a DECnet), POLYCENTER uses the file size from the PDF, rather 
than reading the size of the file itself at the point of use. The result is that the 
newly created file may be corrupt. This problem does not occur if the operation is 
done locally. 

PRODUCT Command — /OUTPUT Not Supported 

The DCL PRODUCT command does not support the /OUTPUT qualifier, which 
would be useful especially for PRODUCT SHOW commands. 

Digital expects to correct this problem in a future release. 

PRODUCT SHOW OBJECT Qualifiers 

The /DIRECTORY and /DEVICE qualifiers to the PRODUCT SHOW OBJECT 
command do not work correctly. The utility either ignores them or provides 
output that does not match the qualifiers. 

Digital expects to correct this problem in a future release. 
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3.22.9 Product Removal Restrictions 

V6.1 Removing a product with the POLYCENTER Software Installation utility results 

in the removal of accounts created for that product. This happens regardless of 
whether the SYSUAF.DAT file is shared by another system disk. 

The same problem exists with rights identifiers and the file RIGHTSLIST.DAT. 

Digital expects to correct these problems in a future release. 

3.23 RMS Journaling 

The following notes pertain to RMS Journaling for OpenVMS. 

Remote Access of Recovery Unit Journaled Files 

Nodes that host recovery unit journaled files that are to be accessed remotely 
from other nodes in the network must define SYS$NODE to be a Phase IV style 
node name. The node name specified by SYS$NODE must be known to any 
remote node attempting to access the recovery unit journaled files on the host 
node, and must be sufficiently unique for the remote node to use this node name 
to establish a DECnet connection to the host node. 

VFC Format Sequential Files Partially Supported for Before-Image or 
Recovery Unit Journaling 

You cannot update variable fixed-length control (VFC) sequential files when 
using before-image or recovery unit journaling. The VFC sequential file format 
is indicated by the symbolic value FAB$C_VFC in the FAB$B_RFM field of the 
FAB. The following error condition results if you attempt to update a VFC format 
sequential file marked for before-image journaling, or on a VFC format sequential 
file modified within a recovery unit: 

JNS, operation not supported by RMS journaling 

For more information about this error message, see the RMS Journaling for 
OpenVMS Manual. 

Digital expects to remove this restriction in a future release of RMS Journaling 
for OpenVMS. 

WRTJNL_BIJ Error Message 

The WRTJNL_BIJ error message may return a zero completion status value 
(STV) rather than the message DEVICEFULL if the device on which the 
before-image journal resides becomes full when RMS is trying to write to the 
before-image journal. If you receive a zero STV in this situation, submit a 
Software Performance Report (SPR). 

3.24 Security Changes 

This section contains a summary of all the security changes introduced in 
OpenVMS AXP Version 6.1, followed by specific notes related to security. These 
changes also appear in OpenVMS VAX Version 6.0 and later. 


3.23.3 

V5.0 


3.23.1 

V6.1 


3.23.2 

V5.0 
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3.24.1 Summary of Changes 

V6.1 OpenVMS Version 6.1 offers significant enhancements to system security. Sites 

interested in implementing the new security features can find a comprehensive 
overview of changes in the OpenVMS AXP Version 6.1 New Features Manual. 
Whether or not you choose to implement the features, note the following changes 
because they can affect your daily operations: 

• The auditing subsystem is different from what existed in earlier versions. 
Chapter 9 of the OpenVMS Guide to System Security explains how auditing 
works in Version 6.1. Note the following changes, in particular: 

— Auditing characteristics are now permanent and distributed clusterwide. 

— Alarm ACEs no longer send event messages to the system audit log file. 
For a permanent record of events, use Audit ACEs to write access events 
to the system audit log file. 

— Alarm message text is not written to the operator log file 
(OPERATOR.LOG). 

— The operating system does not allow logins if it is unable to open the 
system audit log file. 

— When you redirect the audit log file, the change takes place immediately. 
You no longer need to enter the DCL command SET AUDIT/NEW_LOG. 

— The audit server now monitors the audit log file to determine how much 
disk space is available for audit event messages, and when space runs 
low, it preallocates blocks (Section 3.24.8). 

• Captive and restricted accounts have changes in spawn operations: 

— By default, captive accounts cannot use the DCL command SPAWN 
(Section 3.24.5). 

— The Mail utility (MAIL) and DECTPU now allow the SPAWN command in 
restricted accounts (Section 3.24.5). 

• With access control entries (ACEs) carrying the Hidden, Nopropagate, or 
Protected attribute, there is a change in the way DCL commands perform 
copy operations (Section 3.24.18). 

• The default protection for disks and tapes has changed (Section 3.24.6.1). 

• OpenVMS now performs a read and write access check on unshared devices 
($QIO) (Section 5.3, OpenVMS Guide to System Security ). 

• Terminal ownership is changed at login from the value in the template to 
the UIC of the process logging in (Section 5.3.5, OpenVMS Guide to System 
Security). This change is necessary because in Version 6.0, the operating 
system checks for read and write access to a terminal. 

• Objects with a UIC of [0,0], such as devices, no longer have control access by 
default (Section 3.24.2). 

• The READALL privilege no longer grants control access (Appendix A, 
OpenVMS Guide to System Security). 

• With terminal devices, default protection and ownership are no longer set by 
the system parameters TTY_DEFPROT and TTY_OWNER. The operating 
system now uses the security profile template DEVICE.TERMINAL to set the 
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3.24.2 

V6.1 


default protection and owner (Section 3.24.16 in this book and Section 5.3, 
OpenVMS Guide to System Security). 

• The $ASSIGN system service once required read access to a device to assign 
a channel, but now the system service permits assignment if a process has 
read, write, or control access ( OpenVMS System Services Reference Manual). 

• Prior to Version 6.1, the security characteristics for volumes and devices were 
combined but now volumes and devices have separate UICs, protection codes, 
and ACLs (Section 3.24.15 in this book and the OpenVMS Guide to System 
Security.) 

• Batch and print queues have different access requirements: 

— Prior to Version 6.1, submitting a job to a queue required read access and 
submitting a job with the /DELETE qualifier required delete access. Now, 
additional checks are performed when the job executes. 

— Displaying queue security information now requires read access to the 
queue. 

— Read and delete access to queues differs, depending on whether access 
is granted through a protection code or an ACL (Section 5.7, OpenVMS 
Guide to System Security). 

• When you create a new version of a file, the file system now checks for write 
access to the previous file version. Although the old version is not modified, 
superseding the file effectively alters the data that existed. 

• The rights database is no longer world readable ( OpenVMS AXP Version 6.1 
New Features Manual.) 

• The system services $FIND_HELD, $ASCTOID, and $IDTOASC now check 
the requestor’s access to an identifier under certain conditions (Section 8.6.7, 
OpenVMS Guide to System Security). 

Access Restriction to Objects with UIC [0,0] 

The Check Access ($CHECK_ACCESS) and Check Protection ($CHKPRO) system 
services now deny control access to objects with the user identification code (UIC) 
[ 0 , 0 ]. 

In previous versions of the operating system, the $CHKPRO and $CHECK_ 
ACCESS system services granted full access to objects with an owner UIC of [0,0] 
and an empty access control list (ACL). Granting full access did not compromise 
system security because, in general, the only objects owned by [0,0] were devices. 
To change the security profile for a device, you had to have privileges. (The 
SET PROTECTION/DEVICE command requires OPER privilege, and the SET 
ACL/CLASS=DEVICE command requires SYSPRV or BYPASS privilege). 

The system now uses the SET SECURITY and SHOW SECURITY commands 
(which invoke the $CHECK_ACCESS and $CHKPRO system services) to 
manipulate the security profile for all types of objects consistently. If you 
have control access to an object, you can change the security profile for the object. 
Therefore, control access to objects with a UIC of [0,0] is no longer granted by 
default. 
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3.24.3 

V6.1 


3.24.4 

V6.1 


3.24.5 

V6.1 


3.24.6 

V6.1 


Alarm Access Control Entries — No Permanent Record 

Prior to OpenVMS AXP Version 1.5, an Alarm_Journal access control entry (ACE) 
reported an alarm to security operator terminals and to the audit log file. The 
Alarm_Journal ACE has been renamed Alarm ACE and now generates the alarm 
only. 

To obtain a permanent record, add an Audit ACE to each file that currently has 
an Alarm ACE or replace the Alarm ACE on each file with an Audit ACE. 

ANALYZE/AUDIT in a Mixed-Version Cluster 

In a mixed-version cluster, an audit log file contains entries from systems running 
different versions of the operating system. To analyze the log file, you must 
invoke the Audit Analysis utility (ANALYZE/AUDIT) from a node running 
Version 6.1. 

If you invoke ANALYZE/AUDIT from a node running an earlier version of 
OpenVMS AXP, it fails. 

Captive and Restricted Accounts — SPAWN and LIB$SPAWN Changes 

Beginning with OpenVMS AXP Version 6.1, restricted accounts can use the 
DCL command SPAWN within the Mail utility or DECTPU. This change makes 
it possible to use the RESTRICTED flag to force additional authentication or 
authorization checks within a login command procedure (or SYLOGIN) without 
otherwise affecting a user’s environment. Restricted accounts now behave like 
regular accounts once the initial login sequence has completed. 

Also, OpenVMS AXP Version 6.1 prohibits all uses of the SPAWN command or 
the RTL routine LIB$SPAWN within captive accounts unless it is defined as 
trusted. A new /TRUSTED qualifier can be used to connote spawn requests that 
are trusted to perform their functions in a secure manner. A new flag bit (%X40) 
has been defined for the FLAGS argument to the LIB$SPAWN routine. This 
change was made in response to a large number of problem reports about SPAWN 
commands originating in captive command procedures (for example, "SPAWN 
@TT:"). 

To preserve compatibility with existing applications that run in captive accounts 
and contain LIB$SPAWN calls, a flag bit (%X40) in the new SECURITY_ 
POLICY system parameter can be set to allow captive accounts to continue to use 
SPAWN commands and LIB$SPAWN calls. Assuming the default value for the 
SECURITY_POLICY parameter (7), use the following commands to set this flag: 

$ RUN SYS$SYSTEM:SYSMAN 
SYSMAN> PARAM USE CURRENT 

SYSMAN> PARAM SET SECURITY_POLICY 71 ! 64+7 
SYSMAN> PARAM WRITE CURRENT 

Disk and Tapes — Access Control Lists Restored After System Reboots 

For disk and tape devices that are available clusterwide, OpenVMS now stores 
security profiles in a permanent database. The system resets the owner, 
protection code, and ACL automatically for a device when the system reboots. 

You do not need to execute SET ACL (or SET SECURITY) commands in your 
system startup file to restore ACLs. 
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3.24.6.1 

V6.1 


_ Note _ 

If you have a mixed-version cluster, you must manage the different nodes 
in the cluster according to the version of OpenVMS AXP running on the 
node, as follows: 

• On systems running versions of OpenVMS AXP prior to Version 6.1— 
The system startup files must include SET ACL commands to restore 
ACLs on disk devices. 

• On systems running OpenVMS Version 6.1—The system startup 
files must not include SET ACL commands, because the SET ACL 
command changes the device ACL (not the volume ACL). For more 
information about device and volume ACLs, see Section 3.24.15. 


Default Access to Devices 

In previous versions of OpenVMS AXP, a device had an owner UIC of [0,0] and 
the following default protection code: 

System:RWED, Owner:RWED, Group:RWED, World:RWED 

In previous versions, this type of protection allowed any user to access the device. 
When a user dismounted a volume, the system reset the device protection to these 
default values. 

In OpenVMS AXP Version 6.1, the default protection for devices is as follows: 

• The owner UIC is [SYSTEM] 

• The UlC-based protection code is (System:RWLP, Owner:RWLP, Group:R, 
World:) 

When applied to shareable devices, access types have the following definitions: 


Access Type 

Definition 

Read 

Write 

Logical I/O 

Physical I/O 

The right to issue read requests to the device 

The right to issue write requests to the device 

The right to issue logical I/O requests to the device 

The right to issue physical I/O requests to the device 


To initialize or mount a volume on a device, you must have read, write, or control 
access to the device. (There are also some additional requirements for initializing 
a volume that are unrelated to device protection.) System managers (users in the 
system category) and users with the privilege SYSPRV have this type of access. 

The system manager, who has control access, can change the protection. For 
example, to change the protection code for the device DUAO, the system manager 
can enter the following command: 

$ SET SECURITY/PR0TECTI0N=(S:RWLP,0:RWLP,G:RW,W:RW)/CLASS=DEVICE DUAO: 

This command changes the current protection code to allow any user to initialize 
or mount a volume on the device DUAO. Access to the device is then similar to 
the access allowed in previous versions of the operating system. 
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_ Note_ 

Once a volume is mounted, the device protection has no effect on file 
operations on the mounted volume. 


Device Protection — Reverting to Previous Scheme 

Sites at which small numbers of unprivileged individuals must be able to allocate 
tape drives or disk drives for mounting private volumes may want to add access 
control lists (ACLs) to those devices and grant a general identifier to those 
individuals who are permitted to perform such allocation. 

For sites where large numbers of unprivileged individuals must be able to allocate 
tape drives or disk drives, and where there is no concern about “denial of service” 
due to some user controlling such a device, the following procedure can be used to 
revert to the previous device protection scheme on a global basis: 

SYS$EXAMPLES:RESET_DEVICE_PROTECTION.COM 

Disk Space for Audit Log File Now Preallocated 

The audit server preallocates disk space to the security audit log file to ensure 
there is adequate space for event messages. Whenever the file runs low on 
available blocks, the audit server extends the audit log file. Use the DCL 
command DIRECTORY/SIZE/ALL to determine how much of the allocated disk 
space is being used. 

Logical Name Table Ownership 

OpenVMS AXP Version 6.1 changes the default owner of a group logical name 
table. In earlier releases, the default owner was [<group>,0]. The current default 
is [<group>,*]. 

Because the operating system takes the user number from the template profile 
LOGICAL_NAME_TABLE.GROUP, you can configure a system where group 
tables are owned by [<group>,0] by modifying the template, as follows: 

$ SET SECURITY/CLASS=SECURITY_CLASS/PROFILE=TEMPLATE=GROUP - 
_$ LOGICAL_NAME_TABLE /OWNER=[0,0] 

3.24.10 Password History Changes 

This section contains changes to password history. 

3.24.10.1 History Records Removed on Deletion of User Account 

V6.1 Prior to OpenVMS AXP Version 6.1, password history records associated with 

a user account were not removed from the password history database when the 
user authorization record was removed from the system user authorization file 
(SYSUAF). Starting with OpenVMS AXP Version 6.1, associated password history 
records are removed from the password history database whenever a user account 
is deleted. 


3.24.8 

V6.1 


3.24.9 

V6.1 


3.24.7 

V6.1 
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3.24.10.2 

V6.1 


3.24.11 

V6.1 


3.24.12 

V6.1 


3.24.13 

V6.1 


Passwords Older Than Password History Lifetime Now Valid 

The OpenVMS password history database maintains a history of previous 
passwords associated with each user account. By default, the system retains 
these history records for one year. Prior to OpenVMS AXP Version 6.1, old history 
records were removed only after a successful password change. This means that a 
user was unable to change a password to one that existed in the password history 
database even when the matching entry was older than the system password 
history lifetime. 

At the request of several customers, this behavior has been changed. Password 
history records that are older than the password history lifetime are no longer 
considered valid and are allowed as valid password choices. 

PRINT/USER Command Requires Legitimate Access 

To meet C2/B1 security requirements, the queuing system performs additional 
access checking to make sure users have legitimate access to files being printed. 

In OpenVMS AXP versions prior to Version 6.1, the PRINT/USER command 
allowed you to print a file for a user who otherwise would not have access to the 
file. Similarly, the PRINT/USER/DELETE command allowed you to have a file 
deleted on behalf of a user who did not have delete access to the file. 

In OpenVMS AXP Version 6.1, the user specified in the /USER qualifier must 
have read access to the file being printed. In addition, the user must have delete 
access to any file printed with the PRINT/USER/DELETE command. 

For more information on the /USER and /DELETE qualifiers of the PRINT 
command, see the OpenVMS DCL Dictionary. 

Privilege Auditing in a Mixed-Version Cluster 

OpenVMS AXP Version 6.1 allows you to audit all use of privilege by operators 
and system administrators. In a mixed-version cluster, you can enable privilege 
auditing only on those nodes running Version 6.1. 

For nodes running Version 6.1, privilege auditing does not report the use of 
privilege in privileged, installed images. For example, the system does not record 
a privilege audit event when someone enters the SHOW USERS command (which 
invokes an image installed with the WORLD privilege). This audit filtering both 
reduces the amount of overhead required for privilege auditing and ensures that 
the system audits only the actual use of privilege by privileged processes. 

In a mixed-version cluster, when a request is initiated from within a privileged 
image on a node running an earlier version of software, the Version 6.1 system 
cannot detect that the remote image was installed. Therefore, the system always 
generates a privilege audit event. This explains why privilege audit events 
instigated by images installed with privilege can appear in the audit log file. 

ODS-2 Disk Volumes Are Fully Supported Protected Objects 

You can now use ACLs to protect ODS-2 disk volumes. The entire security profile 
(owner UIC, protection code, and ACL) is stored on the volume. If you change 
the volume security profile for a volume mounted clusterwide, the change is 
distributed to all the nodes in the cluster. If you dismount and remount a volume, 
the security profile for the volume is preserved. 

In previous versions of the operating system, protection for ODS-2 disk volumes 
was limited to the owner UIC and a protection code. 
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3.24.14 OpenVMS Systems Require a Single Security Domain 

VI.5 The OpenVMS operating system cannot enforce a level of separation needed to 

support different security domains on separate cluster members. Therefore, the 
OpenVMS VAX and OpenVMS AXP operating systems do not support multiple 
security domains. 

The easiest way to ensure a single security domain is to maintain a single copy of 
each of the following files on one or more cluster-mounted disks. When a cluster 
is configured with multiple system disks, system logical names can be used to 
ensure that only a single copy of each file exists. 

SYS$MANAGER:AUDIT_SERVER.DAT (AXP pre-Version 6.1 and VAX 
pre-Version 6.0 only) 

SYS$MANAGER:VMS$AUDIT_SERVER.DAT 
SYS$SYSTEM:NETOBJECT.DAT 
SYS$SYSTEM:NETPROXY.DAT 
SYS$SYSTEM:NET$PROXY.DAT (VAX only) 

S YS $ S Y STE M: QM AN $M ASTER. DAT 

SYS$SYSTEM:RIGHTSLIST.DAT 

SYS$SYSTEM:SYSALF.DAT 

SYS$SYSTEM:SYSUAF.DAT 

SYS$SYSTEM:SYSU AFALT.DAT 

SYS$SYSTEM:VMS$OB JECTS.DAT 

SYS$SYSTEM:VMS$PASSWORD_HISTORY.DATA 

S Y S $ S Y STEM: VMSM AIL_PROFILE. DATA 

SYS$LIBRARY:VMS$PASSWORD_DICTIONARY.DATA 

SYS$LIBRARY:VMS$PASSWORD_POLICY.EXE 

Using shared files is not the only way of achieving a single security domain. 
Digital fully recognizes the needs of its many existing customers who, for various 
reasons, already choose to use multiple copies of one or more of these files on 
different nodes in a cluster. Such configurations are fully supported as long 
as the security information available to each node in the cluster is exactly the 
same. The security-relevant portions of these files must be synchronized across 
all cluster members to ensure that a single security domain exists. See the 
OpenVMS Guide to System Security for information on synchronizing the files. 

3.24.15 Volumes and Devices Maintain Separate Access Control Lists 

V6.1 In previous versions of the operating system, the security characteristics for 

devices and volumes were combined. When you mounted a volume on a device, 
the system combined the owner UIC and protection code for the volume with the 
ACL (if any) for the device. If you needed an ACL to control access to a volume, 
you had to set the ACL on the device first and then mount the volume. There 
was no separate ACL for the volume itself. 

You can now define an ACL as part of a volume profile. It is the volume profile, 
and not the device profile, that controls access to a mounted volume. The device 
profile controls who can allocate or mount a volume on the device. 
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3.24.16 

V6.1 


3.24.17 

V6.1 


3.24.18 

V6.1 


Terminal Ownership and Protection — Template Security Profile 

In previous versions of the operating system, the system parameter TTY_PROT 
set the default protection for all terminals in relation to the UIC specified by the 
system parameter TTY_OWNUIC. 

In OpenVMS AXP Version 6.1, a template security profile sets the owner and 
protection of terminals. To display the default terminal template for your site, 
enter the following command: 

$ SHOW SECURITY/CLASS=SECURITY_CLASS DEVICE.TERMINAL 
To modify the site template, use the following command 
$ SET SECURITY/CLASS=SECURITY CLASS - 

_$ /PR0FILE=TEMPLATE=TERMINAL7PR0TECTI0N=(PR0TECTI0N_C0DE) - 
_$ /OWNER=NEW_UIC DEVICE 

You cannot set security characteristics by using the DPT_STORE entries in device 
drivers. 

Security Profile Changes Distributed Clusterwide 

A VMScluster system is now a single security domain. If you change the security 
profile for a volume or a device mounted clusterwide, your changes are distributed 
to the other nodes in the cluster. 

In previous versions of the operating system, changes to volume and device 
security profiles were not distributed to the other nodes in a cluster. You could 
use the SET VOLUME command to change the owner UIC or protection on a 
volume. SET VOLUME modified the security profile on disk and the security 
profile in memory. However, if the volume was mounted on another node in 
the cluster, the profile on that other node remained unchanged. To make a 
clusterwide change in the security profile, you had to dismount and remount the 
volume on the other nodes or enter the SET VOLUME command on the other 
nodes. This is no longer necessary. 

SET ACL Qualifiers /LIKE and /DEFAULT — Change in Propagation of 
Protected and Hidden ACEs 

OpenVMS AXP Version 6.1 changes the way the DCL commands SET ACL 
/LIKE (superseded by the new command SET SECURITY/LIKE) and SET ACL 
/DEFAULT (superseded by SET SECURITY/DEFAULT) copy ACEs with the 
PROTECTED and HIDDEN attributes. The changes are as follows: 

• In previous versions of the operating system, the /LIKE qualifier and the 
/DEFAULT qualifier deleted the existing ACL (including PROTECTED ACEs) 
on the target object before copying the ACL. In Version 6.1, ACEs with the 
PROTECTED attribute are not deleted. In other words, you can copy an ACL 
to an object without overwriting any protected ACEs on the target object. 

• In previous versions, the /LIKE qualifier did not copy ACEs with the HIDDEN 
attribute to the target object. In Version 6.1, the HIDDEN attribute does not 
prevent the ACE from being copied. 

As a result of these changes, you can propagate an ACL without losing 
information that is protected or hidden. This is particularly useful for preserving 
ACEs that identify data-dependent information. For example, DDIF files have 
an ACE that identifies the file as DDIF. Utilities, such as TYPE, check the ACE 
before extracting text in the DDIF file. In previous versions of the operating 
system, these data-dependent attributes were lost (even if they were marked 
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as PROTECTED or HIDDEN) when you changed the ACL on a set of files. 
Without the ACEs, which provided data-dependent information, the files became 
inaccessible. 

3.24.19 Auditing — New Events 

V6.1 The system can now audit ill-formed internal calls (identified by NSA$M_ 

INTERNAL) to the $AUDIT_EVENT, $CHECK_PRIVILEGE, $CHKPRO, or 
$CHECK_ACCESS system service. These events indicate that some privileged 
code (having at least AUDIT privilege) has failed to properly audit some event. 
This may be a serious problem for managing system security, but it does not 
indicate a breach in system security. 

This auditing can be controlled using the AUDIT=ILLFORMED keywords with 
the SET AUDIT /ENABLE or /DISABLE commands. See the OpenVMS DCL 
Dictionary for information on SET AUDIT. 

3.24.20 SET AUDIT — Auditing Event Keywords 

V6.1 The system can audit improperly formed internal calls to the $AUDIT_EVENT, 

$CHECK_PRIVILEGE, $CHKPRO, or $CHECK_ACCESS system service. It is 
the NSA$M_INTERNAL flag that identifies an internal call. 

These events indicate that some privileged code, having at least AUDIT privilege, 
failed to properly audit some event. This may be a serious problem for managing 
system security but does not indicate a breach in system security. 

This auditing may be controlled using the AUDIT=ILLFORMED keywords with 
the /ENABLE or /DISABLE qualifier of the SET AUDIT command. The event is 
enabled by default in new installations. 

See the OpenVMS DCL Dictionary for a listing of other event keywords. 

3.24.21 SET AUDIT/FAILURE_MODE=WAIT Is Obsolete 

V6.1 The SET AUDIT command qualifier /FAILURE_MODE is now obsolete. The 

system no longer fails in its attempts to write a security alarm to a security 
terminal. 

3.24.22 SET RIGHTS_LIST/ENABLE DCL — Default Set of Identifier Attributes 

V6.1 Starting with OpenVMS AXP Version 6.1, the SET RIGHTS_LIST/ENABLE DCL 

command now includes a default set of identifier attributes for the identifier being 
enabled or modified. The default attributes are taken from the associated holder 
record of the UIC identifier of the process issuing the command. If the identifier 
is not held by the process, the attributes default to the natural attributes (that is, 
the set of attributes associated with the identifier when it was first created). The 
SET RIGHTS_LIST command uses the /ATTRIBUTE qualifier to add or subtract 
attributes as necessary. 

Prior to OpenVMS AXP Version 6.1, there was no default. All the required 
attributes had to be separately listed using the /ATTRIBUTES qualifier. System 
managers may want to search existing DCL command procedures for any SET 
RIGHTS_LIST/ENABLE commands and consider whether such commands 
still produce the desired effect. In most cases, simply removing any existing 
/ATTRIBUTES qualifiers will result in the desired behavior. 
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3.24.23 SET SECURITY and SHOW SECURITY Replace SET ACL and SHOW 
ACL 

V6.1 In Version 6.1, the DCL commands SET SECURITY and SHOW SECURITY allow 

you to set and display security attributes with a single security management 
interface. These commands replace several DCL commands, including SET ACL 
and SHOW ACL. When you use the new commands, note that they differ from 
the SET ACL and SHOW ACL commands in the following ways: 

• SET ACL and SHOW ACL operate only on the ACL of an object. SET 
SECURITY and SHOW SECURITY operate on the whole security profile, 
including the owner and the UlC-based protection code. For example, SET 
ACL/DEFAULT or SET ACL/LIKE modify only the ACL for an object. SET 
SECURITY/DEFAULT and SET SECURITY/LIKE change the entire security 
profile. 

• In keywords and qualifiers that identify the class of an object, SET 
SECURITY and SHOW SECURITY use the word CLASS. SET ACL and 
SHOW ACL use OBJECT_TYPE. For example: 

$ SET SECURITY/CLASS=DEVICE DUAO: /ACL=(ID=JOE,ACCESS=NONE) 

$ SET ACL/OBJECT_TYPE=DEVICE DUAO: /ACL=(ID=JOE,ACCESS=NONE) 

• To create a new ACL that replaces an existing ACL, SET ACL uses the /NEW 
qualifier and SET SECURITY uses /DELETE=ALL. For example: 

$ SET ACL SAFE.DAT/ACL=(ID=JOE,ACCESS=NONE)/NEW 
$ SET SECURITY SAFE.DAT/ACL=(ID=JOE,ACCESS=NONE)/DELETE=ALL 

• Both SET SECURITY and SET ACL provide a /LIKE qualifier, which specifies 
that the ACL of the target object is similar to the source. Both commands 
allow you to specify the name and class of the source object. However, the 
default class is different. If you do not specify the class of the source object, 
SET SECURITY uses the class of the target object. SET ACL uses FILE as 
the default class. For example: 

$ SET SECURITY/CLASS=DEVICE DUAO: /LIKE=(CLASS=FILE , NAME=SAFE.DAT) 

$ SET SECURITY/CLASS=DEVICE DUAl: /LIKE=NAME=DUAO: 

$ SET ACL/OBJECT_TYPE=DEVICE DUAO: /LIKE=NAME=SAFE.DAT 

$ SET ACL/OBJECT_TYPE=DEVICE DUAl: /LIKE=(OBJECT_TYPE=DEVICE,NAME=DUA0:) 

3.25 Shared Linkage Sections — Restriction 

V6.1 If you want to use an alternate version of any library installed with shareable 

linkage, it is essential to use alternate (noninstalled) versions of all the libraries 
that call that library. The libraries that may be installed with shared linkage are 
LIBOTS, LIBRTL, CMA$TIS_SHR, DPML$SHR, and DECC$SHR. 

The dependencies are in the order listed. 

For example, if you issue the command: 

$ DEFINE DPML$SHR SYS$LIBRARY:DPML$SHR.EXE; 

then you must also issue the command: 

$ DEFINE LIBOTS SYS$LIBRARY:LIBOTS.EXE; 

Failure to redefine all calling libraries may result in access violations. 
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3.26 Symmetric Multiprocessing 

The following notes pertain to symmetric multiprocessing. 

3.26.1 Symmetric Multiprocessing Extension License 

VI.5 With Version 1.5 of the OpenVMS AXP operating system, you must register the 

Symmetric Multiprocessing (SMP) Extension License if you have an SMP system. 
This license upgrades the Operating System Base License and all Interactive 
User licenses (including Unlimited) to the matching multiprocessing level of your 
system. 

Because the Symmetric Multiprocessing (SMP) Extension License grants all the 
rights the existing Base and User licenses provide at the uniprocessing level, you 
do not need to reinstall those licenses when you upgrade to a multiprocessing 
system. Each time you upgrade your system to a new multiprocessing level (for 
example, from a DEC 7000 Model 620 AXP system to a DEC 7000 Model 630 
AXP system), you simply add an SMP Extension License to your existing licenses. 

3.26.2 Restrictions 

VI.5 With the following exceptions, the level of SMP functionality is identical to that 

found on VMS Version 5.4: 

• Primary switching is not supported. 

• The system parameter MULTIPROCESSING, which can be modified by both 
the System Generation utility (SYSGEN) and SYSBOOT, supports a new 
optional value of 4. This optional value guarantees that the streamlined 
system synchronization image is loaded, regardless of the multiprocessing 
capability or number of CPUs within the system. 

The Alpha AXP architecture adds additional constraints on the ordering and 
availability of memory accesses between CPUs in SMP configurations, requiring 
stricter synchronization requirements than those that work on VAX systems. 

Ordering of memory references and atomicity problems cause unpredictable 
results if standard VAX SMP synchronization techniques are not used. However, 
any code sequences that use these techniques are adequately protected in the 
AXP environment without further modification. For additional information 
about synchronization techniques, see Migrating to an OpenVMS AXP System: 
Planning for Migration. 

3.27 System Disks Connected to HSC Devices 

VI.5 Digital recommends that you use high-priority HSC requestors when connecting 

system disks to HSC devices. Refer to the HSC User Guide for information about 
requestor priorities. 

3.28 System Management Utility 

VI.5 The following sections describe changes, known problems, and restrictions that 

apply to the System Management utility (SYSMAN). 
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3.28.1 SYSMAN DO Command 

V6.1 The SMIserver fails under certain conditions for SYSMAN users with large 

numbers of rights identifiers associated with their accounts. Therefore, OpenVMS 
Version 6.1 has a temporary restriction limiting the number of rights identifiers 
that SYSMAN users can hold. SYSMAN users are limited to 60 rights identifiers 
per account. This limitation is an inclusive total of all process, system, image, 
and extended rights. 

Users should be aware that this rights limitation includes a minimum of three (3) 
identifiers that are granted during login when the process rights list is created: a 
UIC identifier, a system identifier, and, depending upon the environment in which 
the process is operating, at least one environmental identifier. 

If a SYSMAN user, running with more that 60 total rights identifiers, attempts to 
invoke a SYSMAN command, SYSMAN returns the following message: 

SMI-E-RIGHTSLIM, Temporary restriction: rights limit exceeded 

Users wishing to run SYSMAN must either have a separate account with no more 
than 60 rights or have enough identifiers removed from the current account to 
make the total number fall within the appropriate range. Creating or modifying 
accounts in this manner is usually done by the system manager. 

This issue will be resolved in a future release of OpenVMS. 

3.28.2 /CLUSTER Qualifier — Problem 

VI. 5 When the system management environment is set clusterwide with the 

/CLUSTER qualifier, entering the following SYSMAN command sometimes 
causes a hang: 

SYSMAN> DO SHOW DEVICE device-name 

This hang is caused by a communication failure between the process spawned by 
the DO command and the remote SMISERVER process on one of the AXP nodes 
in the cluster. 

To work around this problem, press Ctrl/C to return to the SYSMAN> prompt. 
Delete the remote SMISERVER process on the node that did not respond. You 
can then restart the SMISERVER process with the following command: 

$ @SYS$SYSTEM:STARTUP SMISERVER 

If the DO SHOW DEVICE device-name command hangs on the next attempt, 
press Ctrl/C to return to the SYSMAN> prompt. Delete and then restart the 
SMISERVER process on the unresponsive node. Log in to the node that stopped 
responding, and enter the DO SHOW DEVICE device-name command. 

Digital expects to fix this problem in a future release of the OpenVMS AXP 
operating system. 

3.28.3 No Secondary Error Messages for PARAMETERS SET and 
PARAMETERS SHOW Commands — Problem 

VI.5 When you enter the PARAMETERS SHOW or PARAMETERS SET command 

and specify a parameter that does not exist on the AXP platform, SYSMAN 
does not return a secondary error message. The following example shows the 
informational primary message that SYSMAN currently returns when invalid 
parameters are specified: 
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SYSMAN> PARAMETERS SHOW KFILSTCNT 
%SYSMAN-I-NODERR, error returned from node FLAM21 

SYSMAN> PARAMETERS SET KFILSTCNT 16 
%SYSMAN-I-NODERR, error returned from node FLAM21 

The following example shows the secondary error message that SYSMAN should 
return: 

SYSMAN> PARAMETERS SHOW KFILSTCNT 
%SYSMAN-I-NODERR, error returned from node FLAM21 
-SMI-E-NOSUCHPARM, no such parameter 

SYSMAN> PARAMETERS SET KFILSTCNT 16 
%SYSMAN-I-NODERR, error returned from node FLAM21 
-SMI-E-NOSUCHPARM, no such parameter 

Digital expects to fix this problem in a future release. 

3.28.4 Performing Clusterwide DISKQUOTA Commands — Restriction 

VI.5 Normally, SYSMAN DISKQUOTA commands for disks that are mounted 

clusterwide can be performed with the environment set to a single node. The 
clusterwide operation is done at the XQP level. 

If the environment is set clusterwide using the /CLUSTER qualifier, the following 
message is displayed, and the operation still finishes correctly clusterwide: 

%SMI-S-DQCLUS, device is mounted clusterwide, CLUSTER environment ignored 

However, until further notice, when you use the following DISKQUOTA 
commands for clusterwide operation, you must first set the environment 
clusterwide by using the /CLUSTER qualifier: 

• DISKQUOTA ENABLE/DEV=c/ci;jcc 

• DISKQUOTA BISABEE/BEV=device 

If these commands are performed with the environment set to a single node, the 
disk quota for the clusterwide-mounted device is enabled or disabled for that node 
only. 

The following example shows the correct usage and behavior of the DISKQUOTA 
ENABLE and DISKQUOTA DISABLE commands: 

SYSMAN> SET ENV/CLUSTER 

%SYSMAN-I-ENV, current command environment: 

Clusterwide on local cluster 

Username TESTUSER will be used on nonlocal nodes 
SYSMAN> DO SHOW DEV TEST01$DKA100: 


ISYSMAN-I-OUTPUT, 

command execution 

on 

node TEST02 




Device 

Device 


Error 

Volume 

Free 

Trans 

Mnt 

Name 

Status 


Count 

Label 

Blocks 

Count 

Cnt 

TEST01$DKA100: 

Mounted 


0 

TESTVOL 

832395 

1 

4 

%SYSMAN-I-OUTPUT, 

command execution 

on 

node TEST03 




Device 

Device 


Error 

Volume 

Free 

Trans 

Mnt 

Name 

Status 


Count 

Label 

Blocks 

Count 

Cnt 

TEST01$DKA100: 

Mounted 


0 

TESTVOL 

832395 

1 

4 

%SYSMAN-I-OUTPUT, 

command execution 

on 

node TEST04 




Device 

Device 


Error 

Volume 

Free 

Trans 

Mnt 

Name 

Status 


Count 

Label 

Blocks 

Count 

Cnt 

TEST01$DKA100: 

Mounted 


0 

TESTVOL 

832395 

1 

4 

%SYSMAN-I-OUTPUT, 

command execution 

on 

node TEST01 




Device 

Device 


Error 

Volume 

Free 

Trans 

Mnt 

Name 

Status 


Count 

Label 

Blocks 

Count 

Cnt 

TEST01$DKA100: 

Mounted 


0 

TESTVOL 

832395 

1 

4 
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SYSMAN> DISKQUOTA SHOW */DEV=TEST01$DKA100: 

%SYSMAN-I-NODERR, error returned from node TEST02 
-SYSTEM-F-QFNOTACT, disk quotas not enabled on this volume 
%SYSMAN-I-NODERR, error returned from node TEST03 
-SYSTEM-F-QFNOTACT, disk quotas not enabled on this volume 
%SYSMAN-I-NODERR, error returned from node TEST04 
-SYSTEM-F-QFNOTACT, disk quotas not enabled on this volume 
%SYSMAN-I-NODERR, error returned from node TEST01 
-SYSTEM-F-QFNOTACT, disk quotas not enabled on this volume 
SYSMAN> DISKQUOTA ENABLE/DEV=TEST01$DKA100: 

SYSMAN> DISKQUOTA SHOW */DEV=TEST01$DKAl00: 

%SMI-S-DQCLUS, device is mounted clusterwide, CLUSTER environment ignored 
%SYSMAN-I-QUOTA, disk quota statistics on device TEST01$DKA100: — 

Node TEST02 

UIC Usage Permanent Quota Overdraft Limit 

[ 0 , 0 ] 0 1000 100 

[VMS,TESTUSER] 25 1000 100 

SYSMAN> DISKQUOTA DISABLE/DEV=TEST01$DKA100: 

SYSMAN> DISKQUOTA SHOW */DEV=TEST01$DKAl00: 

%SYSMAN-I-NODERR, error returned from node TEST02 
-SYSTEM-F-QFNOTACT, disk quotas not enabled on this volume 
%SYSMAN-I-NODERR, error returned from node TEST03 
-SYSTEM-F-QFNOTACT, disk quotas not enabled on this volume 
%SYSMAN-I-NODERR, error returned from node TEST04 
-SYSTEM-F-QFNOTACT, disk quotas not enabled on this volume 
%SYSMAN-I-NODERR, error returned from node TEST01 
-SYSTEM-F-QFNOTACT, disk quotas not enabled on this volume 
SYSMAN> 

3.29 System Parameters 

The following sections pertain to system parameters. 

3.29.1 AWSTIME and QUANTUM System Parameters 

V1.0 Some application configurations (for example, a large number of memory¬ 

intensive processes) may benefit if the values of the AWSTIME and QUANTUM 
system parameters are reduced. The value for both parameters should be 
identical and can be as low as 4. 

3.29.2 ITB_ENTRIES Parameter Removed 

V6.1 The system parameter ITB_ENTRIES has been removed from OpenVMS AXP. 

3.29.3 System Parameter PIOPAGES 

V6.1 The default value for the system parameter PIOPAGES has been increased 

to 336 pages. RMS buffers and data structures for process-permanent files 
(for example, SYS$INPUT) and files opened by the DCL command OPEN are 
allocated from PIOPAGES. The value of the system parameter PIOPAGES thus 
can affect the number of such files that can be opened at any one time from a 
single process. The new default value of 336 PIOPAGES has been chosen to 
support approximately the same number of concurrently open process-permanent 
and DCL-opened files under OpenVMS AXP Version 6.1 as was supported under 
earlier versions of OpenVMS. 

The exact number of such concurrently open files depends on the buffer size 
associated with the files, as well as other factors in your environment. The 
buffer size for indexed and relative files is determined by the maximum bucket 
size for each file, and for sequential files by the multiblock count. For example, 
with PIOPAGES set to 336 in OpenVMS AXP Version 6.1, you should be able to 
open, in addition to the process-permanent files (SYS$INPUT, SYS$OUTPUT, 
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SYS$COMMAND, SYS$ERROR), approximately the following maximum number 
of local indexed files: 


Bucket Size 

Maximum Files 

63 

1 

32 

2 

16 

4 

8 

8 

4 

13 

2 

18 

1 

22 


For PIOPAGES of 336, the maximum number of concurrently open remote files is 
15, regardless of buffer size. 

You may get different results depending on the particular mix of file organizations 
and buffer sizes present in your DCL environment. The previous figures are 
approximate and are intended only as a guide. 

RMS Journaling under OpenVMS Version 6.1 will use PIOPAGES for certain 
internal data structures when RU journaling has been enabled for files opened 
by the application. When RU has been enabled, PIOPAGES may be temporarily 
allocated by RMS for the duration of a single RMS operation. 

For example, under OpenVMS Version 6.1, most recovery unit journaled $PUT, 
$UPDATE, or $DELETE operations will require at least 8.2 pagelets (VAX 512- 
byte pages) of PIOPAGES for the duration of these operations. In addition, a 
typical call to SYS$END_TRANS or SYS$ABORT_TRANS to end a recovery 
unit may require approximately 16.5 pagelets of PIOPAGES for the duration of 
these operations. These figures are approximate, and may vary depending on the 
characteristics of your application. 

While the need for additional PIOPAGES is temporary over the duration of 
the operation, RU applications that make extensive use of asynchronous RMS 
operations may have several such operations launched at the same time, and thus 
make heavier demands on their PIOPAGES. This might be true, for example, if 
your application employs its own threading scheme to interface with RMS. 

These applications should calculate their additional PIOPAGES requirements by 
estimating the maximum number of outstanding RMS operations that may occur 
at any one time from within the same VMS process, then use the guidelines in 
the previous paragraph to estimate their PIOPAGES usage. 

3.30 Terminal Fallback Facility (TFF) 

VI.0 The Terminal Fallback facility (TFF) includes a fallback driver 

(SYS$FBDRIVER.EXE), a shareable image (TFFSHR.EXE), a terminal fallback 
utility (TFU.EXE), and a fallback table library (TFF$MASTER.DAT). 

• To start TFF, invoke the TFF startup command procedure located in 
SYS$MANAGER, as follows: 

$ @ S YS $MANAGER:TFF $ SYSTARTUP.COM 
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V6.1 


3.31 

3.31.1 

V6.1 


• To enable fallback or to change fallback characteristics, invoke the Terminal 
Fallback utility (TFU), as follows: 

$ RUN SYS$SYSTEM:TFU 
TFU> 

• To enable default fallback to the terminal, issue the following DCL command: 
$ SET TERMINAL/FALLBACK 

OpenVMS AXP TFF differs from OpenVMS VAX TFF in the following ways: 

• On AXP systems, the TFF fallback driver is named SYS$FBDRIVER.EXE. 
On VAX systems, the TFF fallback driver is named FBDRIVER.EXE. 

• On AXP systems, TFF is capable of handling 16-bit character fallback. The 
OpenVMS AXP fallback table library (TFF$MASTER.DAT) contains four 
more 16-bit character tables than the VAX library. Table 3—1 describes these 
additional tables. 


Table 3-1 TFF Character Fallback Tables 


Table Name 

Base 

Description 

BIG5_HANYU 

BIG5 

BIG5 for CNS 11643 (SICGCC) terminal/printer 

HANYUJBIG5 

CNS 

CNS 11643 (SICGCC) for BIG5 terminal/printer 

H ANYU_TE LEX 

CNS 

CNS 11643 for MITAC TELEX-CODE terminal 

HANGUL_DS 

KS 

KS for DOOSAN 200 terminal 


These tables are used mainly by the Asian region. Also, the table format was 
changed due to the support of 16-bit character fallback. 

• On AXP systems, the TFU command SHOW STATISTICS does not display 
the size of the fallback driver (SYS$FBDRIVER.EXE). 

RT terminals are not supported by TFF. 

For more information about the Terminal Fallback facility, refer to the OpenVMS 
Terminal Fallback Utility Manual. 


_ Note _ 

TFFSHR has been removed from IMAGELIB because it is not a 
documented, user-callable interface. The image is still available in 
the SYS$LIBRARY: directory. 


UETP Notes 

The following sections pertain to UETP (User Environment Test Package). 

UETP Documentation Relocated 

In previous OpenVMS releases, the documentation for UETP software was 
provided in the OpenVMS upgrade and installation manuals. With this OpenVMS 
release, UETP documentation has been moved to the OpenVMS System Manager's 
Manual: Tuning , Monitoring, and Complex Systems. 
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3.31.2 

V6.1 


3.32 

3.32.1 

V6.1 


3.32.2 

V6.1 


Adding Special Accounts 

Effective with this release, the user names SYSTEM, SYSTEST, and SYSTEST_ 
CLIG are automatically created as part of a fresh installation. Some sites may 
also want to create a Field Service account for use by regularly assigned Field 
Service personnel. 

To create accounts for UETP or Field Service, a new command procedure is 
provided that can be invoked with the command: 

$ @SYS$MANAGER:CREATE_SPECIAL_ACCOUNTS.COM 

In contrast to former practice, this command procedure allows choice of the user 
name for Field Service personnel. It permits assignment of separate user names 
to individuals for better accountability and also reduces the risk of successful 
outside attacks against a known user name such as FIELD. 

Digital still recommends that privileged accounts described above be disabled 
when not in use and that generated passwords be used for Field Service accounts. 

VMScluster Systems 

The following sections contain information pertaining to VMScluster systems. 

FDDI Clusters — Restriction Removed 

To enable FDDI clustering on OpenVMS AXP Version 1.5, you were required 
to set the system parameter PE3 to 1. For OpenVMS AXP Version 6.1, this 
requirement has been removed. 


_ Note _ 

Effective with OpenVMS AXP Version 6.1, if you set the system parameter 
PE3 to 1, the results are unpredictable. 


Improved Concurrency in VMScluster Systems 

OpenVMS AXP Version 6.1 provides an improved file system. This improved file 
system is also available as part of OpenVMS VAX Version 6.1, and as a special 
release, known as the XQP+ for PATHWORKS. 

One of the features provided by the improved file system is improved concurrency, 
which allows multiple processes to create files on a single disk in parallel. 

If you are in a VMScluster system, do not turn on improved concurrency unless 
all the nodes are running the improved file system. Each node in the VMScluster 
system must be running one of the following: 

• OpenVMS AXP Version 6.1 

• OpenVMS VAX Version 6.1 

• XQP+ for PATHWORKS 

If you are running the improved file system on all the nodes in your VMScluster, 
turn on improved concurrency by setting the static XQPCTL2 system parameter 
to 1. 
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3.32.3 TMSCP Tape Serving Support for AXP Systems 

V6.1 With OpenVMS AXP Version 6.1, TMSCP tape serving is supported on AXP 

processors. AXP systems can serve TMSCP tapes to either AXP or VAX systems 
in a VMScluster system. Prior to this release, only VAX processors could serve 
TMSCP tapes. 

See VMScluster Systems for OpenVMS for more information about TMSCP tape 
serving. 

3.33 VMSINSTAL Checks Process Quotas 

VI.5 At the beginning of a layered product installation, VMSINSTAL examines a 

number of process quotas in the installation account. VMSINSTAL determines 
whether the quotas are adequate for the installation of the product and notifies 
you if they are not. 

Process quota values vary with the type and version of the operating system in 
use, as shown in Table 3—2. 


Table 3-2 Minimum VMSINSTAL Installation Process Quotas 


Process Quota 

Minimum Value for 

OpenVMS VAX Version 6.0 1 

Minimum Value for 

OpenVMS AXP Version 1.5 1 

ASTLM 

40 

24 

BIOLM 

40 

18 

BYTLM 

32768 

32768 

DIOLM 

40 

18 

ENQLM 

200 

200 

FILLM 

300 

100 


1 In future releases of the OpenVMS AXP operating system, minimum values may increase. Similarly, 
minimum values shown for OpenVMS VAX Version 6.0 may change in future releases. 


A layered product may require additional process quotas or higher process quota 
values than those shown in Table 3-2. For specific information, see the layered 
product’s installation guide. 


_ Note _ 

Use the Authorize utility (AUTHORIZE) to change process quota values. 
Changes that you make do not take effect until you log out and log in 
again. 


3.34 Volume Shadowing 

The following sections pertain to volume shadowing software. 

3.34.1 Volume Shadowing — Problems Fixed 

The following sections contain corrections in the Volume Shadowing for OpenVMS 
AXP software. 
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3.34.1.1 Correction to SCSI Disk Problem 

V6.1 In Volume Shadowing for OpenVMS AXP Version 1.5, you were advised to not put 

SCSI devices in the same shadow set if they were connected locally to the same 
AXP host. System failures and other types of failures could occur when doing 
memory management I/O on locally attached shadowed SCSI disks. 

However, you could include SCSI disks in a shadow set when the SCSI disks 
were: 

• Connected to different AXP computers 

• MSCP served from VAX and AXP computers in the same VMScluster system 

This restriction has been corrected in Volume Shadowing for OpenVMS AXP 
Version 6.1, and a remedial kit is available for OpenVMS AXP Version 1.5 
customers. 

3.34.1.2 Correction to KZMSA Adapter Problem on DEC 7000 AXP Systems 

V6.1 Prior to OpenVMS AXP Version 6.1, disks on DEC 7000 AXP systems that were 

connected to a VMScluster system through a KZMSA device were not protected 
against media failure from defects. A media defect refers to an imperfection in 
the oxide coating on the surface of the disk platter. Over time, the oxide degrades, 
resulting in a loss of data. This type of failure is extremely rare, but it is one that 
shadowing is expected to protect against. 

You were able put these disks in shadow sets, but this meant that disks on this 
adapter were removed from the shadow set in the rare occurrence of a media 
defect. 

This problem has been corrected for OpenVMS AXP Version 6.1. 

3.34.1.3 Correction to KDM70 Controller Problems 

V6.1 Prior to OpenVMS AXP Version 6.1, disks attached to the cluster using the 

KDM70 controller were not supported in shadow sets. Devices on this type of 
controller experienced a high number of “invalid MSCP command” errors under 
load. This resulted in their removal from the shadow set. 

This problem has been corrected for OpenVMS AXP Version 6.1. 

3.34.2 Volume Shadowing Restrictions 

V6.1 This section contains restrictions for Volume Shadowing for OpenVMS AXP. 

3.34.2.1 Phase I Shadowing Not Supported 

V6.1 Phase I (controller-based) volume shadowing is not supported on Volume 

Shadowing for OpenVMS AXP Version 6.1; only phase II (host-based) shadowing 
is supported. Phase II shadowing is designed to replace phase I with significantly 
enhanced data availability and a much wider range of configurations, disk 
controllers, and disks. 

If any VAX nodes in your VMScluster system are still using phase I and they 
need to access shadowed data from an AXP node, they must migrate to phase II. 

See Appendix A of Volume Shadowing for OpenVMS for instructions on how to 
convert from phase I to phase II. 
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3.34.2.2 Shadow Set Devices Must Be Identical Types 

V6.1 The physical units (disk devices) that are members of the same shadow set 

must be the same type of disk and have the same physical geometry. To assure 
this, the volume shadowing software performs two checks: first for the device 
identification (ID) and then for the maximum number of logical block numbers 
(LBNs). If either of these items does not match, the devices cannot be mounted 
as members of the same shadow set. 

For example, the RZ28 and the RZ28B (often sold as a replacement for the RZ28) 
do not have the same device IDs and cannot be members of the same shadow set. 
However, two RZ28Bs could be included in a two-member shadow set. 

3.34.2.3 Shadow Set Members Connected to KD* Controllers 

V6.1 If a shadow set member is a disk connected to a KDA, KDB, or KDM controller, 

then the system dynamic parameters SHADOW_MBR_TMO and SHADOW_SYS_ 
TMO should both be increased to 600 in every node in the VMScluster system 
where the shadow set is mounted. This will prevent premature timeout and 
removal of that disk from the shadow set when the system serving that disk to 
the VMScluster system is rebooted, crashes, or halts. 

3.34.2.4 VMScluster System Hangs on DISMOUNT/CLUSTER Command 

V6.1 A known problem may very rarely cause a clusterwide hang as a result of the 

DISMOUNT command. This problem happens when the DISMOUNT/CLUSTER 
command that you issued to a shadow set hangs. The process that issued the 
command may wait for a reply from a remote node in the VMScluster system. 
Unfortunately, the process on this remote node holds an exclusive lock, preventing 
other nodes from dismounting the shadow set. 

To work around this problem, you can use the DISMOUNT/SYSTEM command 
(rather than DISMOUNT/CLUSTER) from each node in the VMScluster system 
to dismount the shadow set. Then reboot the nodes in the VMScluster system 
that serve the devices included in the shadow set. 

RZ57 Not Supported in Shadow Sets 

For DEC 3000 systems only, OpenVMS supports the RZ57 disk drive with device 
revision level D01 and microcode revision 6000. 

Disks that meet these conditions can be shadowed. 

3.35 Watch Chip — Change in Time Range 

VI.0 AXP systems maintain their system time during power failures and system down 

time with a watch chip (BBW). This chip replaces the time-of-day register (TODR) 
used on VAX systems. The BBW chip allows a range of only one century, placing 
a greater constraint on the dates that can be accepted by the $SETIME service 
and SET TIME DCL commands. What used to be a wider date range on VAX 
systems is now limited to the century between 1957 and 2056. 

In addition, a set of sanity checks has been added to the system boot routines 
to validate the format of the BBW and the values put into it by previous system 
boots. These checks recognize out-of-bounds values. When the time is known to 
be earlier than the last time modification or greater than 5 years in the future, 
you are prompted to enter the time at the console prompt. Such situations may 
occur when an AXP computer, after running another operating system such as 
OSF/1, is rebooted using the OpenVMS AXP operating system. 


3.34.2.5 

V6.1 
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3.36 XCDAC Adapter Storage-Only Support Available 

VI.5 The XCDAC adapter (the XMI to Cl adapter with an NPORT driver interface) 

is available in Version 1.5 for storage purposes only. A supported configuration 
consists of a dedicated star coupler, a single DEC 7000 Model 600 AXP computer, 
and multiple HSC controllers. 

The XCDAC hardware is identical to the CIXCD hardware, except for the 
addition of new microcode. The XCDAC adapter is supported on all AXP XMI 
machines (DEC 7000 Model 600 AXP computers). 

3.37 X Terminal Support 

VI.5 This release of OpenVMS AXP supports remote X sessions over LAT lines. In 

Version 1.0, X terminals could create only local DECterm processes and could 
connect to an AXP system only like a terminal server. In Version 1.5, X terminals 
can create LAT X sessions. 

To set up your system for X terminal use, enter the following commands after 
your system boots: 

$ DEFINE /SYSTEM DECW$INSTALL_XTERMINAL TRUE 
$ @SYS$MANAGER:DECW$STARTUP "XTERMINAL" 

If you want to have X terminal setup performed automatically when the system 
boots, place the following line in the SYS$MANAGER:SYLOGICALS.COM file: 

$ DEFINE /SYSTEM DECW$INSTALL_XTERMINAL TRUE 

The DECwindows startup procedure at the end of the system boot invokes the 
SYS$STARTUP:DECW$STARTXTERMINAL.COM procedure, which in turn 
installs appropriate images and starts up the X terminal font daemon (the 
DECW$FD process). 

Once the system boots, you can make a LAT X connection from an X terminal. 
Startup of a LAT X session is actually performed from the X terminal itself. The 
X terminal font daemon is also included with this release. As a result, you can 
set an X terminal’s font path to an AXP system (via LAT). 

With this release, you can use LAT as a transport to an X terminal in order to 
display a DECwindows application. The following example shows how to run a 
DECwindows application and display it on an X terminal (assuming security on 
the terminal is set appropriately): 

$ SET DISPLAY /CREATE /TRANSP0RT=LAT /NODE=LAT_08002Bxxxxxx 
$ RUN SYS$SYSTEM:DECW$PUZZLE 

In the example, xxxxxx is specific to the user’s X terminal. The example shows 
how to set the display back to the X terminal and then run a DECwindows 
application (in this case, PUZZLE). The application is displayed on the specified 
X terminal. 

For more information about X terminal configuration, refer to the X terminal 
documentation that accompanied your terminal. 
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VMScluster Systems 


With this release of OpenVMS AXP, Digital is extending VMScluster support to 
include the latest releases of OpenVMS AXP and OpenVMS VAX in the same 
VMScluster system. Digital is also supporting several pairings of OpenVMS 
versions in a VMScluster system. 

This chapter describes the following: 

• Support for mixed-version and mixed-architecture VMScluster systems 

• Guidelines for developing applications for mixed-architecture VMScluster 
systems 

• Components or functions not available in past releases that can affect a 
VMScluster system 

• Functional equivalence issues that can affect a VMScluster system 

4.1 Support for Mixed-Version and Mixed-Architecture VMScluster 
Systems 

OpenVMS VAX Version 6.1 provides two levels of support for mixed-version 
and mixed-architecture VMScluster systems: warranted support and migration 
support. 

Warranted support means that Digital has fully qualified the two versions 
to coexist in a VMScluster system and will answer all problems identified by 
customers using these configurations. Warranted support is provided for several 
pairs of OpenVMS VAX and OpenVMS AXP versions. (See Figure 4—1.) 

Migration support means that Digital has qualified the versions for use together 
in configurations that are migrating in stages to a newer version of the OpenVMS 
VAX or OpenVMS AXP operating system. 

Migration support is a superset of the rolling upgrade support provided in earlier 
OpenVMS releases and is available for pairs that are not warranted. Problem 
reports submitted against these configurations will be answered by Digital. 
However, in exceptional cases Digital may request that you move to a warranted 
configuration to correct the problem. Migration support will help customers move 
to warranted VMScluster version pairs with minimal impact on their cluster 
environments. 

Figure 4-1 shows the level of support provided for all possible version pairings. 

To find the level of support for a version pair, select one version in the top row 
and read down the column below it until you intersect with the line for another 
version listed in the left column. 
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4.1 Support for Mixed-Version and Mixed-Architecture VMScluster Systems 

Figure 4-1 OpenVMS Version Pairings 
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In many cases, more than two versions will successfully operate in a VMScluster 
system, but Digital cannot commit to resolving problems with such configurations. 

4.2 Rolling Upgrades 

Rolling upgrades in a mixed-architecture system are performed in the same way 
that rolling upgrades in a single-architecture VMScluster or VAXcluster system 
are performed. 

4.3 Guidelines for Developing Applications for Mixed-Architecture 
VMScluster Systems 

These guidelines are provided for software developers who are interested in 
having their applications run in a mixed-architecture VMScluster system. 

A basic assumption about applications running in a mixed-architecture 
VMScluster system is that they should work just as they do in a single¬ 
architecture VMScluster or VAXcluster system. VMScluster components, such 
as the lock manager, RMS, and the connection manager, behave the same in a 
mixed-architecture VMScluster as they do in a single-architecture VMScluster or 
VAXcluster system. 

Most OpenVMS VAX applications require some migration work to run on an AXP 
computer. The exceptions are the few applications that utilize only simple DCL 
commands, that is, they do not run any application images. In general, you need 
to at least recompile and relink your application so that it will run on an AXP 
computer. 

For an application to work in a mixed-architecture VMScluster system, consider 
the following aspects of an application: 

• User interface 

• System management interface 

• Interactions between the application executing on VAX and AXP nodes 
— File format compatibility 

— Data packing and buffer size 
— Data-type selection 
— Buffer size 
— Data access and locking 

• Missing features 


4-2 









Mixed-Version and Mixed-Architecture VMScluster Systems 
4.3 Guidelines for Developing Applications for Mixed-Architecture VMScluster Systems 


Neither users nor system managers should notice a difference in the behavior of 
the application, regardless of whether the node in a VMScluster system is a VAX 
or an AXP system. Users should expect to see better application performance 
on OpenVMS AXP systems. System managers should expect to maintain 
architecture-specific copies of image files. Other differences should be minimized. 

Application compatibility with mixed-architecture VMScluster systems can vary, 
depending on the degree of differences visible to users and system managers. 

The following sections should help you determine how well your application will 
function in a mixed-architecture VMScluster environment and what modifications 
may be necessary. 

4.3.1 User Interface 

User interfaces for a given application should be identical on both VAX and AXP 
nodes. At a minimum, one implementation of the user interface should be a 
subset of the other. In addition, the differences may need to be noted in user 
documentation. 

4.3.2 System Management 

The system management aspects of an application pertain to the similarity of the 
installation and licensing mechanisms on both VAX and AXP. The goal for the 
application developer is to minimize the work required for managing different 
architectural versions of applications that are running in the mixed-architecture 
VMScluster system. 

4.3.3 File Format Compatibility 

It is important to clearly differentiate between two kinds of files—image files 
(including shareable images (.EXE)) and application data files. Image files cannot 
be activated across architectures. An image built for VAX will run only on a VAX 
computer and an image built for AXP will run only on an AXP computer. If an 
application kit is to be shared by AXP and VAX systems, it must either contain 
separate images for each platform, perform the link during the installation, or 
use DECmigrate for OpenVMS AXP Systems to translate the application. Note 
that DECmigrate is an optional product, released separately from the OpenVMS 
VAX operating system. 

A common kit will probably need conditional statements for linking, as the 
process for linking shareable images differs between VAX and AXP systems. 
F$GETSYI (“ARCH_TYPE”) can be used from DCL. The number 1 means you are 
executing on a VAX system, while a 2 indicates that you are on an AXP system. 

Applications should be able to share data files across the AXP and VAX systems; 
doing so is usually required for the application to run properly in a mixed- 
architecture VMScluster environment. 


_ Note _ 

If full data file compatibility cannot be achieved, applications should 
ensure that the incompatible format is recognized by both types of 
systems and an error message is issued. 
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4.3.4 Data Packing 

Aligned data can provide significant performance improvements on VAX systems 
(up to 4 times faster) and on AXP systems (up to 100 times faster). Unaligned 
data was typical on older VAX systems where minimal consumption of memory 
was very important and data was packed tightly together, ignoring alignment 
issues. 

If you share data between AXP and VAX systems, avoid unaligned data 
structures. Use at least longword alignment for in-memory data structures 
whenever possible; quadword alignment is preferred, if possible. 

If you have a real-time application or an application that exhibits poor file I/O 
characteristics and shares data through a file, you may find it advantageous to 
align the file data structures. 

For more information, see OpenVMS Compatibility Between VAX and AXP and 
Migrating to an OpenVMS AXP System: Recompiling and Relinking Applications. 

4.3.5 Data-Type Selection 

Check to see if your application depends on the size or bit representation of 
an underlying data type. Ideally, all data accessed by different nodes in the 
VMScluster system should have the identical format on VAX and AXP nodes. 
Examples include the following: 

• Only ASCII, integer, or F and G VAX floating-point data formats are used in 
files (no H_float, no IEEE float, no machine instructions). 

For Fortran, this can be relaxed, since Fortran provides run-time support 
for automatic conversion between floating-point types via the /CONVERT 
compiler qualifier, and so forth. 

• All structures stored in files are equally aligned for VAX and AXP systems. 

Different data formats can be used if format translation is transparent to the 
user. 

Support for floating-point data types differs between OpenVMS VAX and 
OpenVMS AXP systems, as shown in Table 4-1. 


Table 4-1 Floating-Point Data Type Support 


Data Type 

On VAX 

On AXP 

D53_float (G_ 
float) (Default 
double-precision 
format) 

Not supported. 

Supported. Using D53_float instead of D56_float 
drops three bits of precision and yields slightly 
different results. 

D56_ float (Default 

double-precision 

format) 

Supported. 

Not supported. You can obtain full support 
by translating your code with DEemigrate. 
Alternatively, you can substitute D53_float for 
D56_float, if your application does not require 
the extra three bits of precision. 

F_float 

Supported. 

Supported. 

G_float 

Supported. 

Supported. 

(continued on next page) 
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Table 4-1 (Cont.) Floating-Point Data Type Support 


Data Type 

On VAX 

On AXP 

H_float (128-bit 
floating-point) 

Supported. 

Not supported. You can obtain full H_float 
support with DECmigrate. You can use it to 
translate the code module that contains H_float 
structures, or you can recode your application, 
using a supported data type. 

S_float (IEEE) 

Not supported. 

Supported. 

T.float (IEEE) 

Not supported. 

Supported. 

X_float (128-bit 

floating-point 

(IEEE)) 

Not supported. 

Supported by DEC Fortran Version 6.2 and by 
DEC C Version 4.0. The X_float data format is 
not identical to H_float, but both cover a similar 
range of values. For Fortran applications, 
automatic conversion between X_float memory 
format and H_float on-disk is possible by use 
of the /CONVERT compiler qualifier, or the 
CONVERT= option on OPEN statements. 


You may want to use the IEEE floating-point formats on AXP systems for 
coexistence with other open systems. However, using the IEEE floating-point 
formats may impede mixed-architecture VMScluster interoperability, because the 
T, S, and X IEEE floating-point data types are not supported on VAX systems. 

For Fortran programs, this is not a major obstacle because of the /CONVERT 
compiler qualifier or the CONVERT= option on OPEN statements. For C 
programs, the automatic conversion of binary floating-point data in files is not 
possible, so this is an issue. 

If your VAX application requires full 56-bit precision, that is, the D56_float data 
type, or if it requires the H_float data type, you can translate your image with 
DECmigrate. Because a translated image runs significantly slower than a native 
AXP image, isolate the set of routines requiring 56-bit D_float precision or the 
H_float data type into its own small image for translation, and run the rest of the 
application native. 

If your application contains data types that are not supported on OpenVMS 
AXP, you can make the changes that are appropriate for it (either translation 
or recoding). You can then port your application to OpenVMS AXP systems and 
share data between AXP and VAX systems in a mixed-architecture VMScluster 
system. For more information about translation support, see the Section 5.35. 

For more information about supported data types, see the documentation for the 
compiler you are using. 

4.3-6 Buffer Size 

If you need to make changes to your code, such as aligning data structures 
and using different data types, you will need to review the buffer sizes in your 
application. Such changes generally require larger buffers. 

4.3.7 Data Access and Locking 

Data access is synchronized using the same resource names and locking 
sequences on VAX and AXP nodes. This is not new for mixed-architecture 
VMScluster systems, since the need to ensure resource naming conventions 
is standard for VMScluster systems today. However, you should test your 
application to ensure correct operation. 
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4.3.8 Missing Features 

Check your application for dependencies on features that might not exist on the 
target system (see Section 4.6). Also, check your application for dependencies 
on features provided by middleware applications that might not exist on the 
target system. Because a feature or application may not be available on both 
platforms, using the feature or application in a mixed-architecture VMScluster 
system could yield unanticipated results. One example is DECnet/OSI full name 
support, which is available in OpenVMS VAX Version 6.1 but is not yet available 
on OpenVMS AXP Version 6.1. If an application uses the full name capability 
and works across a VMScluster system, there may be an interoperability issue. 

4.4 Application Compatibility Checklist 

Use the following checklist to determine how well your application will work in a 
mixed-architecture VMScluster environment. 

1. User Interface 

] Does the application present the same user interface on both 
architectures? 

• If not, is one interface an easily described subset of the other? 

] Does the application use the same documentation on both architectures? 

] Are user interface differences documented for the user? 

] Are error messages the same across the architectures for the same error 
condition? 

2. System Management 

] Are version numbers for feature-compatible versions identical for both 
architectures? 

] Is a single version of the License Management Facility (LMF) possible? 
Can both the VAX and AXP versions of the application run using 
comparable licensing mechanisms? There should not be a requirement 
that the application use LMF Version 1.x on a VAX system and a different 
LMF version on an AXP system. 

] Are separate installations required for each architecture? 

] Does the application use the same installation procedure and 
documentation? 

] Does the application work across architectures without additional system 
management steps? 

] Does the application present comparable failure scenarios and recovery 
capabilities on both architectures? 

3. File Format Compatibility 

] Are all files associated with the application accessible and used equally on 
each architecture? Remember that object and image libraries and image 
files are different between VAX and AXP systems. (Other library types, 
such as .TLB and .HLB, do not present a problem. They are the same.) 

| Can files that do not contain machine instructions be used equally on 
either architecture? 

• Is full compatibility the default or is user action required? 
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• How does the application manage differences in file formats? 

• If your application does not allow files to be shared, does it 
recognize an incompatible file format and present a suitable warning 
message? 

4. Data Packing 

] Does your application use unaligned data structures? 

• If so, what is the performance impact for your application? 

5. Data-Type Selection 

] Does your product use D56_float or H_fioat on VAX? 

• If so, what is the performance impact if you use the emulation 
routines that provide full D56_float or full H_float support? 

• What is the precision-loss impact if you replace D56_float with D53_ 
float? 

6. Buffer Size 

] Will you need to change the alignment of any data structures or any data 
types in your application? 

• If so, what are the implications on buffer size? 

7. Data Access and Locking Compatibility 

] Does your product provide compatibility of resource names? 

] Does your product provide compatibility of locking sequences? 

8. Missing Features 

] Does your product utilize features that are only available on one platform? 

] Are you documenting these differences to your users so they will know 
what will work in a mixed-architecture VMScluster? 

4.5 Components or Functions Not Available in Past Releases 

New features or improvements to existing features are introduced with each new 
release. Even though the feature or improvement is available in both OpenVMS 
AXP Version 6.1 and OpenVMS VAX Version 6.1, its use may be restricted in a 
mixed-version or mixed-architecture VMScluster, if it is not available in earlier 
versions, as described in Table 4-2. 

Table 4-2 Components or Functions Not Previously Available 
Component Description 

Cross-architecture In a mixed-architecture VMScluster running both OpenVMS AXP Version 6.1 

satellite booting and OpenVMS VAX Version 6.1 using DECnet for OpenVMS (DECnet Phase 

IV), AXP boot nodes can provide boot service to VAX satellites, and VAX boot 
nodes can provide boot service to AXP satellites. Cross-architecture satellite 
booting is limited to these two versions. Satellite booting across architectures is 
under investigation for nodes running DECnet/OSI. 

(continued on next page) 
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Table 4-2 (Cont.) Components or Functions Not Previously Available 


Component 

Description 

Monitoring of remote 
nodes 

The Monitor utility has been updated for OpenVMS Version 6.1 on AXP to 
communicate with OpenVMS Version 6.1 on VAX. As a result, MONITOR no 
longer communicates with older versions—Version 1.5 on AXP and Version 5.5-2 
on VAX. 


If you are running in a VMScluster with OpenVMS AXP Version 1.5 or 
OpenVMS VAX Version 5.5-2 nodes, and begin to update your VMScluster, 
you will receive the server mismatch error message when you attempt to use 
remote monitoring between updated and non-updated nodes. You must upgrade 
your entire VMScluster to Version 6.0 or Version 6.1 in order for MONITOR to 
work across all nodes in the VMScluster system. 

Process identifiers limit 

OpenVMS AXP Version 6.1 and OpenVMS VAX Version 6.1 support up to 1024 
identifiers. Previous versions of OpenVMS AXP and OpenVMS VAX support up 
to 256 identifiers. If any nodes in a VMScluster system are running versions 
prior to Version 6.1, the limit of 256 identifiers is in effect. 

Virtual I/O cache 

Virtual I/O cache became available in OpenVMS AXP Version 1.5 running 
standalone and OpenVMS VAX Version 6.0. If any nodes in a mixed-version 
or mixed-architecture VMScluster system are running OpenVMS VAX Version 
5.5-2 or OpenVMS AXP Version 1.5, the virtual I/O cache disables itself. 


4.6 Functional Equivalence Issues 

Functional equivalence means that OpenVMS AXP provides customers with the 
same user environment, security services, system management environment, 
programmer environment, standards compliance, and system integrated 
products as those that are available on OpenVMS VAX, although the software 
implementation or user interface may vary slightly. OpenVMS AXP Version 6.1 
and OpenVMS VAX Version 6.1 are functionally equivalent, with some exceptions 
as represented in Figure 4-2. 

Figure 4-2 Functional Equivalence for OpenVMS VAX and OpenVMS AXP 
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The exceptions to functional equivalence are briefly described in this section. 
Some of these topics are more fully described elsewhere in these release notes 
and in the manuals listed in Table 4—3. 

Most functional equivalence issues arise because a component is available either 
on OpenVMS VAX Version 6.1 or on OpenVMS AXP Version 6.1 but not on both 
systems. Some issues arise because a component, such as ANALYZE/ERROR, 
originally designed to work in a single architecture, does not work across 
architectures in a mixed-architecture VMScluster system. 

The manuals listed in Table 4—3 contain additional information about functional 
equivalence: 


Table 4-3 Documentation Sources for Functional Equivalence Topics 


Topics 

Manual 

Order Number 

Supported applications, hardware 
support, ensuring portable 
applications, and so forth 

OpenVMS Compatibility 
Between VAX and AXP 

AA-PY Q4B-TE 

Recompiling and relinking VAX 
applications, including architectural 
differences that affect portability 

Migrating to an OpenVMS 
AXP System: Recompiling 
and Relinking Applications 

AA-PV63A-TE 

Porting VAX MACRO applications, 
including architectural differences 
that affect portability 

Migrating to an OpenVMS 
AXP System: Porting 

VAX MACRO Code 

AA-PV64B-TE 

System management similarities 
and differences, including 
architectural differences that affect 
system management 

A Comparison of System 
Management on OpenVMS 
AXP and OpenVMS VAX 

AA-PV71B-TE 

Features and functions of OpenVMS 
VAX and OpenVMS AXP and 
supported applications 

OpenVMS Software Overview 

AA-PVXHB-TE 


The functional equivalence issues described in this section are organized in the 
following categories: 

• User environment 

• Security services environment 

• System management environment 

• Programming environment 

• Hardware support 

This section does not address architectural differences. Architectural differences, 
where they affect program development or system management, are described in 
two of the manuals listed in Table 4-3. 

4.6.1 User Environment Issues 

The following issues exist in the user environment: 

• Image activator 

On AXP, if you attempt to start a VAX image, a message is displayed with 
a clear explanation of why you cannot do that. On VAX, the message is 
ambiguous. 

Status: A clear message is planned for a future release of OpenVMS VAX. 
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• RECALL command 

On AXP, the RECALL command can display up to 254 previously entered 
commands. You can also input commands from a file to the recall buffer 
and output commands from the recall buffer to a file. On VAX, the RECALL 
command can display up to 20 previously entered commands. On VAX, you 
cannot input to and output from the recall buffer. 

Status: The same RECALL command enhancements are planned for a future 
release of OpenVMS VAX. 

4.6.2 Security Services Environment Issues 

The following issues exist in the security services environment: 

• Auditing DECnet connections 

On VAX, this support is provided by DECnet for OpenVMS VAX (formerly 
named DECnet-VAX). This support is not provided by DECnet for OpenVMS 
AXP. 

Status: Auditing DECnet connections is under investigation for OpenVMS 
AXP. 

• Auditing events 

On VAX, badly formed audit requests are recorded via the FATAL 
BUGCHECK mechanism. Special audit messages are provided on AXP. 

Status: A better method of handling such requests is planned for a future 
release of OpenVMS VAX. 

• DECnet proxy services 

On VAX, a new proxy system, including a new format database for proxy 
data (NET$PROXY), new proxy system services, and a new security server 
are available. These services provide an application programming interface 
(API) and eliminate the need to write code that depends on undocumented 
OpenVMS file formats. 

In a mixed-version or mixed-architecture VMScluster system with one or 
more nodes running OpenVMS VAX Version 6.1, all proxy changes must 
be done from a node running OpenVMS VAX Version 6.1. OpenVMS VAX 
Version 6.1 uses the new proxy system regardless of whether DECnet for 
OpenVMS VAX (formerly named DECnet—VAX) or DECnet/OSI is being used. 

Status: The DECnet proxy services are planned for a future release of 
OpenVMS AXP. 

• Intrusion system services 

These services provide an API to the intrusion database and eliminate 
the need to write inner mode code. They are available on VAX but not yet 
available on AXP. 

Status: The intrusion system services are planned for a future release of 
OpenVMS AXP. 
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4.6.3 System Management Environment Issues 

The following issues exist in the system management environment: 

• ANALYZE/ERROR 

The ANALYZE/ERROR (ERF) utility is architecture-specific. In other words, 
in a mixed-architecture VMScluster, a user on a VAX node cannot use 
ANALYZE/ERROR to analyze the ERRLOG.SYS of an AXP node, nor can a 
user on an AXP node use ANALYZE/ERROR to analyze the ERRLOG.SYS of 
a VAX node. 

Status: The capability of using ANALYZE/ERROR across architectures is 
under investigation. 

• ANALYZE/IMAGE (/OBJECT) (cross-architecture) 

On AXP, using ANALYZE/IMAGE, you can analyze both AXP and VAX 
images. On VAX, you can only analyze VAX images. Furthermore, if you 
attempt to analyze an AXP image, an unclear message is displayed. 

Status: A correction to the message is planned for a future release of 
OpenVMS VAX. A change to the OpenVMS VAX functionality is under 
investigation. 

• Cluster event notification services 

The cluster event services, available on AXP, detects both VAX and AXP 
membership changes in a VMScluster system. Notification is made using an 
AST. These services do not identify which node joined or left the VMScluster, 
only that the membership changed. The $GETSYI lexical can be used to 
identify actual membership changes. These services are not yet available on 
VAX. 

Status: The cluster event notification services are planned for a future 
release of OpenVMS VAX. 

• Debugger: Heap Analyzer component 

The Heap Analyzer component of the OpenVMS Debugger is available on 
VAX but is not available on AXP. The Heap Analyzer provides a graphical 
representation of memory use in real time. This display helps users quickly 
identify where memory usage and performance could be improved. 

Status: The Heap Analyzer is planned for a future release of OpenVMS AXP. 

• DECamds 

The data collection component of DECamds runs on both VAX and AXP. 
However, the display and user interface component of DECamds runs 
only on VAX. You can run the DECamds data collector on every node in a 
mixed-architecture VMScluster system, but you must run the user interface 
(DECamds Console) on a VAX node. 

Status: Support for the user interface (DECamds Console) is planned for a 
future release of OpenVMS AXP. 

• DECdtm and full names 

On AXP, DECdtm runs with DECnet for OpenVMS AXP (DECnet Phase IV) 
but does not run with DECnet/OSI. This is because complete support for 
DECnet/OSI full names, which are descriptive network node names, is not 
available yet on AXP. On VAX, DECdtm runs with DECnet for OpenVMS VAX 
(DECnet Phase IV, formerly named DECnet-VAX) and with DECnet/OSI. 

Status: Full name support is planned for a future release of OpenVMS AXP. 
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• DECnet DDCMP support 

On VAX, DDCMP lines are supported by DECnet for OpenVMS VAX. On AXP, 
no support is available for DDCMP lines. 

Status: No change is planned. 

• DECnet host-based routing 

On VAX, host-based routing is supported by DECnet for OpenVMS VAX. 

On AXP, no support is available for host-based routing. DECnet/OSI for 
OpenVMS AXP eliminates the need for host-based routing in some cases, 
because it supports multiple circuits on an end system. Dedicated routing 
boxes can be used to handle the remaining cases where host-based routing 
was previously used. 

Status: No change is planned. 

• DECnet/OSI full names 

Descriptive network node names, or full names, are fully supported on VAX, 
but the support is limited on AXP. Applications that rely on full name support 
may not run or may not run properly on OpenVMS AXP Version 6.1. (See the 
application’s documentation.) 

Status: Full name support is planned for a future release of OpenVMS AXP. 

• DIAGNOSE command (DECevent) 

On AXP, the DIAGNOSE command invokes the DECevent utility (DECevent). 
DECevent provides functions and enhancements not available with the Error 
Log utility. It provides the interface between a system user and the system’s 
event log files. DECevent is not available on VAX. 

Status: Providing DECevent for OpenVMS VAX is under investigation. 

• Dynamic load balancing 

Dynamic load balancing, available on VAX, enhances the ability to efficiently 
balance the disk I/O work load in a VAXcluster system. Dynamic load 
balancing is not yet available on AXP. In a mixed-architecture VMScluster 
system, dynamic load balancing is used among the VAX nodes. 

Status: Dynamic load balancing is planned for a future release of OpenVMS 
AXP. 

• F11CD and MOUNT 

AXP provides support for mounting noncompliant 9660 FllCDs but VAX does 
not. If users have noncompliant CD media and are running applications in 
a mixed-architecture VMScluster system (OpenVMS AXP Version 6.1 with 
either OpenVMS VAX Version 6.0 or OpenVMS VAX Version 6.1), they may 
experience problems. This is an issue for PATH WORKS users who are using 
noncompliant 9660 FllCDs in a mixed-architecture VMScluster system. 

Status: Support for mounting noncompliant 9660 FllCDs is planned for a 
future release of OpenVMS VAX. 

• Image registration 

VAX supports image registration but AXP does not. Image registration 
is a mechanism that allows you to continue to run application images 
(including main images, shared libraries, and device drivers) that depend on 
internal interfaces of a previous version of the operating system. For more 
information, see the OpenVMS System Manager's Manual. 

Status: Image registration on OpenVMS AXP is under investigation. 
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• LAT new functions and enhancements 

Several new functions and enhancements to the LAT software are provided 
on AXP but not on VAX. The new functions include the capability for making 
an intrasystem LAT connection and the capability for using SET HOST /LAT 
in a command procedure. 

Status: The new functions and enhancements to LAT are planned for a 
future release of OpenVMS VAX. 

• MOUNT and DISMOUNT 

MOUNT and DISMOUNT are functionally equivalent across architectures. 
However, there are some bug fixes that have been applied only to AXP and 
some that have been applied only to VAX. 

Status: Bugfix similarity for these components is planned for future releases 
of OpenVMS VAX and OpenVMS AXP. 

• ODS-1 files 

Support for ODS-1 files is provided on VAX but not on AXP. 

Status: No change is planned for OpenVMS AXP. 

• Patch utility 

The Patch utility is available on VAX but not on AXP. 

Status: A limited Patch utility for AXP that would provide the PATCH 
/ABSOLUTE function is under investigation. 

• PC SI installation of the operating system 

The POLYCENTER Software Installation (PCSI) utility can be used to install 
certain applications on both VAX and AXP, but only AXP currently supports 
the installation of its operating system with PCSI. 

Status: PCSI installation of the operating system is under investigation for 
OpenVMS VAX. 

• Random password generator 

A random password generator is available on both VAX and AXP. However, 
a different mechanism is used on AXP, which creates more memorable 
passwords. The passwords created on AXP are displayed without hyphens. 

Status: Providing the same random password mechanism on OpenVMS VAX 
is under investigation. 

• SCSI-2 tagged command queuing 

SCSI-2 tagged command queuing, a performance enhancement available on 
VAX, is not yet available on AXP. 

Status: SCSI-2 tagged command queuing is planned for a future release of 
OpenVMS AXP. 

• Shadowing dumpfile failover 

Shadowing dumpfile failover is supported on VAX but not on AXP. Shadowing 
dumpfile failover occurs when one member of a shadowed disk set fails, and a 
system that booted from that member also fails. The dump file, produced by 
the failed system, is saved to another member of the shadowed disk set. 

Status: Shadowing dumpfile failover is under investigation for OpenVMS 
AXP. 


4-13 




Mixed-Version and Mixed-Architecture VMScluster Systems 
4.6 Functional Equivalence Issues 


• SHOW SYSTEM command 

On an AXP node in a mixed-architecture VMScluster, when you issue the 
SHOW SYSTEM command, the operating system is identified in the display 
as OpenVMS. On a VAX node in a mixed-architecture VMScluster, when you 
issue the same command, the operating system is displayed as VAX/VMS. This 
difference can cause problems for applications that parse the SHOW SYSTEM 
display. 

Status: The display will be changed to OpenVMS in a future release of 
OpenVMS VAX. 

Furthermore, in a mixed-architecture VMScluster, you cannot use the SHOW 
SYSTEM/NODE command from either a VAX or AXP node to identify the 
architecture of a target node. 

Status: The capability of using SHOW SYSTEM across architectures is 
under investigation. 

• Snapshot facility 

The Snapshot facility (Snapshot), sometimes referred to as Fastboot, lets you 
reduce system startup time by booting OpenVMS VAX from a saved system 
image disk file. Snapshot can be used only for a standalone VAX workstation 
and is not available on AXP. 

Status: Snapshot is not planned for OpenVMS AXP. 

• SYSMAN utility I/O function 

The SYSMAN utility I/O function, used for loading and connecting drivers, is 
available only on AXP. 

Status: The SYSMAN utility I/O function is under investigation for 
OpenVMS VAX. 

• Writeboot utility (WRITEBOOT) 

The Writeboot utility cannot be used across architectures. In other words, in 
a mixed-architecture VMScluster system, you cannot use AXP Writeboot to 
update a VAX bootblock nor can you use VAX Writeboot to update an AXP 
bootblock. 

Status: The capability of using WRITEBOOT across architectures is under 
investigation. 

4.6.4 Programming Environment Issues 

The following programming environment issues exist: 

• Device drivers written in C 

Device drivers can be written in C for OpenVMS AXP but cannot be written 
in C for OpenVMS VAX. 

Status: No change is planned. 

• System-Code Debugger 

On AXP, the OpenVMS AXP System-Code Debugger, a symbolic debugger, 
is available for debugging device drivers. The System-Code Debugger is not 
available on VAX. 

Status: No change is planned. 


4-14 




Mixed-Version and Mixed-Architecture VMScluster Systems 

4.6 Functional Equivalence Issues 


• Translated images 

DECmigrate for OpenVMS AXP can be used to translate most OpenVMS VAX 
images to run on OpenVMS AXP, but there are some exceptions. For more 
information, see Section 5.35. 

Status: No change is planned. 

4.6.5 Hardware Support Issues 

The following hardware support issues exist: 

• Dynamic device recognition 

Dynamic device recognition is provided on AXP but not on VAX. 

Status: Dynamic device recognition is planned for a future release of 
OpenVMS VAX 

• Dynamic system recognition 

Dynamic system recognition is provided on AXP but not on VAX. 

Status: No change is planned. 

4.6.6 Functional Equivalence Issues Summary 

Most of the functional equivalence issues will be removed in the next maintenance 
and functional releases of OpenVMS VAX and OpenVMS AXP. Table 4—4 shows 
the components for which issues exist, the architecture that currently provides 
the function (or preferred behavior), and the status when or if the function will be 
provided for both architectures, as of April 1994: 

Table 4-4 Functional Equivalence Issues Summary 

Status 


Component 

To be added to 
VAX or AXP? 

Planned 

No Change 

Under 

Investigation 

ANALYZE/ERROR (cross-arch.) 

Both 

- 

- 

X 

ANALYZE/IMAGE (message) 

VAX 

X 

- 

- 

ANALYZE/IMAGE (cross-arch.) 

Both 

- 

- 

X 

Auditing DECnet connections 

AXP 

- 

- 

X 

Auditing events 

VAX 

X 

- 

- 

Cluster event notification services 

VAX 

X 

- 

- 

Debugger, Heap Analyzer 

AXP 

X 

- 

- 

DECamds display 

AXP 

X 

- 

- 

DECdtm full name support 

AXP 

X 

- 

- 

DECnet DDCMP support 

AXP 

- 

X 

- 

DECnet host routing 

AXP 

- 

X 

- 

DECnet proxy services 

AXP 

X 

- 

- 

Device drivers in C 

VAX 

- 

X 

- 

DIAGNOSE (DECevent) 

VAX 

- 

X 

(continued on next page 


4-15 




Mixed-Version and Mixed-Architecture VMScluster Systems 
4.6 Functional Equivalence Issues 



Table 4-4 (Cont.) Functional Equivalence Issues Summary 


Component 

To be added to 
VAX or AXP? 

Planned 

Status 

No Change 

Under 

Investigation 

Dynamic device recognition 

VAX 

X 

- 

- 

Dynamic load balancing 

AXP 

X 

- 

- 

Dynamic system recognition 

VAX 

- 

X 

- 

F11CD and MOUNT 

VAX 

X 

- 

- 

Full names 

AXP 

X 

- 

- 

Image activator (message) 

VAX 

X 

- 

- 

Image registration 

AXP 

- 

- 

X 

Intrusion system services 

AXP 

X 

- 

- 

LAT new functions and enhancements 

VAX 

X 

- 

- 

MOUNT and DISMOUNT bug fixes 

Both 

X 

- 

- 

ODS-1 files 

AXP 

- 

X 

- 

Patch utility 

AXP 

- 

- 

X 

PCSI installation of O/S 

VAX 

- 

- 

X 

Random password generator 
enhancements 

VAX 

- 

- 

X 

RECALL command enhancements 

VAX 

X 

- 

- 

SCSI-2 TCQ 

AXP 

X 

- 

- 

Shadowing dumpfile failover 

AXP 

- 

- 

X 

SHOW SYSTEM (display) 

Both 

X 

- 

- 

SHOW SYSTEM (cross-arch.) 

Both 

- 

- 

X 

Snapshot 

AXP 

- 

X 

- 

SYSMAN I/O 

VAX 

- 

- 

X 

System-Code Debugger 

VAX 

- 

X 

- 

Translated images 

AXP 

- 

X 

- 

WRITEBOOT (cross-arch.) 

Both 

- 

- 

X 
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This chapter contains information of particular interest to programmers, such as 
tools, utilities, system services, and the file system. 

5.1 DEC Ada Run-Time Library 

V6.1 The DEC Ada Run-Time Library (ADARTL.EXE and ADAMSG.EXE) is now 

included as part of OpenVMS AXP Version 6.1. 

5.2 Calling Standard Change Between Native and Translated 
Images 

VI. 5 OpenVMS AXP Version 1.0 did not support calls between translated and native 

images where a structure greater than 32 bits was passed by immediate value in 
a register argument. 

The only language that naturally supports receiving such a call is C (VAX C 
or DEC C for OpenVMS). The following sections should be of interest to those 
who use such calls between native and translated images to routines written 
in the C programming language. It may also interest those who customize 
the autojacketing interface between the translated and native environments of 
OpenVMS AXP, such as constructing their own procedure descriptors. (Such work 
is usually done with MACRO-64 Assembler for OpenVMS AXP Systems.) 

5.2.1 Changes to the Procedure Signature Information Block (PSIG) 

VI.5 The following changes have been made to the procedure signature information 

block (PSIG): 

• A new 64-bit argument, PSIG$K_RA_Q, has been added to the PSIG$_V_ 
REG_ARG_INFO field. This new argument has a value of 1. 

The argument is passed in an integer register in the native environment and 
in 2 longwords within the argument list in the translated environment. The 
new capability treats a 64-bit segment of data (a portion of a structure) as a 
single register argument for the native environment and as two consecutive 
longword entries in the argument list for the translated environment. 
Compilers specify this behavior by using the new PSIG$K_RA_Q register 
argument code in the procedure signature information block. 

The corresponding capability for arguments numbered greater than 6 in the 
native environment (memory arguments) is already present. For the sake 
of consistency, however, a new symbolic name for the corresponding memory 
argument code is provided, as described in the next item. 

• A new symbolic name, MASE$K_MA_Q, replaces the memory argument 
signature bit known as MASE$K_MA_I64. MASE$K_MA_Q is a 64-bit 
argument with a value of 0. 
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The name MASE$K_MA_Q is preferable to the former name (MASE$K_ 
MA_I64) because the new name makes no statement about the argument 
being “integer” when in fact the code is used to support transmission of 
structures and floating-point values across the interface between the native 
and translated environments. 

• Formerly, the symbolic name PSIG$K_RA_I64 in the PSIG$_V_REG_ARG_ 
INFO field had the following two meanings: 

— 64-bit argument passed in an integer register. 

Using the symbolic name PSIG$K_RA_I64 for register arguments is no 
longer recommended because it does not accurately describe the behavior 
triggered by that code. When an argument is present, that code now 
results in behavior identical to that of PSIG$K_RA_I32. 

— Argument is not present. 

A new symbolic name, PSIG$K_RA_NOARG, is defined for the second 
meaning for which register argument code PSIG$K_RA_I64 was used. 
PSIG$K_RA_NOARG means that no argument is present as determined 
from the argument count for the call. 

5.2.2 Versions of Compiled Languages 

VI. 5 Languages that make use of the new procedure signature register argument code 

have a method for expressing the notion of passing structures whose sizes are 
greater than 32 bits by immediate value. 

The following initial versions of OpenVMS AXP compilers do not support this 
capability: 

• DEC Ada Version 3.0 for OpenVMS AXP Systems 

• DEC C Version 1.2 for OpenVMS AXP Systems 

• DEC Fortran Version 6.0 for OpenVMS AXP Systems 

Later versions of these compilers will be able to generate the new procedure 
signature register argument code in appropriate circumstances. The new 
procedure signature register argument code produces the new behavior only 
when run with OpenVMS AXP Version 1.5 or greater. 

Digital suggests that, if you need to pass structures larger than 32 bits between 
the translated and native environments compatibly on both OpenVMS AXP 
Version 1.0 and later versions, pass those structures by reference. This is not a 
problem for MACRO-32 because that language does not provide any method for 
passing a structure larger than 32 bits by immediate value. Other languages not 
listed previously should not encounter any problems with this issue because the 
first OpenVMS AXP official release of the language included this change (if they 
support passing a structure larger than 32 bits by immediate value). 

5.2.3 MACRO-64 Assembler Version 1.0 for OpenVMS AXP Systems 

VI.5 To use Version 1.0 of the MACRO-64 Assembler for OpenVMS AXP Systems and 

generate the new procedure signature register argument code, add the following 
code before invoking any of the regular calling standard macros: 
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MACR064$CALLSTD_DEFS 
MACR064$RA_I64 = 1 
MACR064$RA_i64 = 1 

MACR064$REGARGTYPE_A 
MACR064$REGARGTYPE_a 
MACR064$MEMARGTYPE_F 
MACR06 4 $MEMARGTYPE_f 
MACR06 4 $MEMARGTYPE_S 
MACR06 4 $MEMARGTYPE_s 
MACR064$MEMARGTYPE_UL 
MACR064$MEMARGTYPE_ul 
MACR064 $MEMARGTYPE_A 
MACR064 $MEMARGTYPE_a 


Change MA_I64 to use new MA_Q code (MA_Q = 1). 
(Make MA_I64 pretend to be MA_Q). 

Do initial VI.0 definitions. 

Change RA_I64 to use new RA_Q code. 

Lowercase version too. 


"132" 
"132" 
"132" 
"132" 
"132" 
"132" 
"132" 
"132" 
"132" 
"132" 


Correct VI.0 call signature encodings. 
VAX addresses are longword. 

Lowercase too. 

F_float is a longword in length. 
Lowercase too. 

S_float is a longword in length. 
Lowercase too. 

U32 is a longword. 

Lowercase too. 

VAX addresses are longword. 

Lowercase too. 


This code also corrects some other procedure signature block generation errors 
when you use the MACRO-64 Assembler Version 1.0 for OpenVMS AXP Systems 
to generate calls to translated VAX images (that is, when you invoke the $CALL 
macro with the TIE=TRUE argument). 

These changes do not cause $ROUTINE and $PROCEDURE_DESCRIPTOR to 
accept ARGLIST=Q where it now accepts ARGLIST=I64. You must still use 164 
with $ROUTINE and $PROCEDURE_DESCRIPTOR, even though it will become 
obsolete. 


With any subsequent release of the MACRO-64 Assembler for OpenVMS AXP 
Systems, Digital plans to recommend changing the use of 164 with $ROUTINE 
and $PROCEDURE_DESCRIPTOR to Q (issuing an informational message for 
164 to that effect). $CALL changes will not be necessary because $CALL maps 
from an argument qualifier to the appropriate argument type. 

For more information about the procedure signature information block, see the 
OpenVMS Calling Standard. 


5.3 DEC C Run-Time Library Notes 

The release notes in this section pertain to the DEC C Run-Time Library. 

5.3.1 New Features 

V6.1 The following features of the DEC C Run-Time Library are new for OpenVMS 

AXP Version 6.1: 

• Exceptional values passed to math functions now return values in 
accordance with the X/Open CAE Specification (XPG4). Previously, range 
and domain errors resulted in a return value of zero. See the Digital Portable 
Mathematics Library documentation for details. 

• Improved Printf Formatting of Floating-Point Numbers 

This release has had changes to the printf routines to correct rounding 
errors with the ’gVGVe’/EVP format specifications and changes to enhance 
performance. 
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These changes will cause the number "-(2**126)" to print as follows: 

-(2**126) == -85070591730234615865843651857942052864e0 

D-float: -85070591730234615900000000000000000000.000000 

G-float: -85070591730234616000000000000000000000.000000 

IEEE: -85070591730234616000000000000000000000.000000 

X-float: -85070591730234615865843651857942052900.000000 

The number of significant digits printed by printf is based on the following 
computation: 

2 + floor(logl0(2)*p) 

where p is the number of bits of mantissa in a floating-point representation. 

This yields 17 decimal digits of precision for G and IEEE float, 18 decimal 
digits for D float, and 36 decimal digits for X float. These values are the 
implementation-defined number of decimal digits for which correctly rounded 
conversions are guaranteed. These values are distinct from but close to the 
definitions of DBL_DIG and LDBL_DIG as defined by Section #2.2.4.2.2 of the 
ANSI C standard. These macros define the number of decimal digits that can 
be guaranteed in terms of converting from decimal to floating-point and back. 
These macros are defined as 15 for G and IEEE float, 16 for D float, and 33 
for real* 16 float. 

Therefore, the OpenVMS AXP printf routines now accurately print up to 
the number of decimal digits as specified previously. This is consistent 
with the ANSI C standard. In addition, even though specific values like 
-(2**126) can be exactly represented, there is an upper limit to the number 
of digits of accuracy that the internal float-to-text conversion routines used 
by printf can produce. Therefore, the C RTL would never be able to print 
every large-magnitude, double-precision, floating-point number with an exact 
representation accurately. 

As far as printf for an IEEE implementation, some information on this is 
provided in the Floating-Point C Extensions X3J11 FP/IEEE Subcommittee 
Technical Report, Final Report: Draft #2 WG14/N319, X3J11/94-003. Section 
4.2.2 on Input/Output for IEEE Implementation says the following: 

“If the number of significant decimal digits is at most DECIMAL_DIG, then 
the result from converting a value from an IEEE format is correctly rounded 
for the current rounding direction. If the number of significant decimal digits 
is more than DECIMAL_DIG but the source value is exactly representable 
with DECIMAL_DIG digits, then the result is an exact representation with 
trailing zeros. Otherwise, the source value is bounded by two adjacent 
decimal strings L < U, both having DECIMAL_DIG significant digits; the 
value of the result decimal string D satisfies L <= D <= U, with the extra 
stipulation that the error have the correct sign for the current rounding 
direction.” 

DECIMAL_DIG is defined as an implementation-defined number of decimal 
digits that is supported by conversion between decimal and all internal 
floating-point formats. Conversion from (at least) double to decimal with 
DECIMAL_DIG digits and back should be the identity function. 

The output of the OpenVMS AXP printf routines for IEEE is consistent with 
the previous section for IEEE implementations. 
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5.3.2 

V6.1 


5.3.2.1 

V6.1 


Problems Fixed 

The major focus for the DEC C Run-Time Library group has been on quality. 

There have been numerous problems fixed in this release. The following list is 

divided into categories to help the reader understand the areas of focus. 

Input/Output Subsystem Fixes 

The following notes summarize fixes to the input/output subsystem: 

• The symbols DECC$RECORD_READ and DECC$RECORD_WRITE are now 
universal symbols in the shareable image. 

• Standard input/output operations work correctly when the file opened is a 
mailbox. 

• An optimization was made to the I/O subsystem dealing with stream files that 
eliminates a read for every write done at the end of the file. 

• The RTL has been changed to apply the semantics of "cxt=nocvt" only when 
the file has the FORTRAN carriage-control attributes. Using this option with 
files having different attributes has no effect. 

• The RTL defaults to the process setting of the RMS MBC value. Instead of 
always defaulting to a value of 64, the RTL uses the value set by the user in 
a SET RMS /BLOCK=n command. 

• While the documentation specifies that STREAM, STREAM_CR, and 
STREAM_LF files would default to being opened in "ctx=stm" mode, this 
was not true. This was only true for STREAM_LF files. It is now true of all 
three file types. If record access mode is necessary for your application, then 
an explicit M ctx=rec" is required in the open statement. 

• The RTL now sets the longest record-length attribute of a stream file to 
32767. This value is most likely not the correct value based on the contents of 
the file, but the file can at least be used with facilities such as sort, convert, 
and tpu. 

• If STDOUT is established as a file and the file already exists, the file 
protection is inherited from the previous version of the file. Prior to this 
fix, the default file protections of the process were given to the new file. 

• Problems encountered when both STDERR and STDOUT are the same 
process permanent file have been resolved. The problem was that one of the 
two outputs would go to the file, while the other would be lost. 

• The RTL no longer hangs if a buffer larger than 65535 is passed to the 
setvbuf() function. 

• Calls made to the setvbuf() function no longer change the file position pointer. 

• The lseek() function now behaves correctly when positioning to the last byte 
of the file. 

• Using the lseek() function with a SEEK_CUR parameter after calling the 
write() function now returns the correct file position. The incorrect behavior 
was that the position returned was the position within the file before the 
write operation instead of after the write operation. 

• The fgets() function, when reading from a mailbox, now waits for input to 
arrive instead of returning right away. 

• Using a gets() function call to get arguments supplied in a batch job command 
file no longer causes an access violation. 
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5.3.2.2 

V6.1 


• The function fread() now returns -1 on failure. Previous versions would 
return -1 divided by the size of an item (the second argument). 

• The write() function now operates correctly when the user program has 
disabled ASTs. 

• A problem was fixed in the write() function where asynchronous I/O was used 
by the RTL and the user application called fsynch() directly after the write. 
This caused intermittent failures because the RTL was not calling SYS$WAIT 
prior to calling SYS$FLUSH. 

• The RTL can now write more than 32767 fixed-length records to a file. 

• The fsetpos() function now correctly returns the file position when at the end 
of the buffer. 

• Opening a spooled device using "w" mode no longer gets a File Not Found 
error. 

• The RTL no longer resets the carriage control to NONE if the device is a 
spooled terminal. The carriage control is set to CR in this situation. 

• The stat() function no longer fails when the file name contains a search list 
with concealed, terminal logical names pointing to two different devices and 
the file does not exist in the first directory in the search list. 

• The stat() function now returns the correct number of bytes in an empty 
indexed file. 

• The fgetname() function now returns the current device and directory 
when passed a null file name. This functionality is now compatible with 
the VAXCRTL behavior. 

Printf and Scant Problems Fixed 

The following notes summarize fixes to the printf and scanf functions: 

• The printf() function no longer access violates if virtual memory is exhausted 
when trying to open STDOUT. The function now opens NLAO: in this 
situation. 

• The fprintfO function now returns a status of -1 if a failure occurs while 
writing the data to a disk. The data that failed to be written is not saved 
in the internal buffers. The application programmer may safely retry the 
operation after correcting the reason for failure. 

• When formatting and displaying floating-point numbers using the printf() 
function, the numbers are first rounded appropriately and then displayed as 
if the rounded number had been passed in the first place. For example, if a 
small negative number is rounded to zero, then printing this number using a 
format string of " %6.2f' displays "0.00" with no sign. 

• The function printf() now correctly calculates the width for a format specifier 
of "%#051X". 

• The printf() function no longer gives an extra zero when passed the format 
specifier "%#41o" with a value of zero. 

• The sprintf() function now correctly interprets the format string "%#.4o" to 
result in 4 characters written instead of 5. The test in question used this 
format string with the value 345 to produce the incorrect result of "00531" 
instead of the now correct value of "0531". 
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• The sprintf() function no longer overwrites the return address when the 
precision specified in the format string exceeds 10. 

• A bug in which calling fputs() to print a null string prior to calling printfi) 
to print characters caused the first fprintf() character to disappear has been 
fixed. 

• Printf now correctly rounds items with ’g’/GYeYEyf’ format specifications. 
Previously, a rounding bug caused some numbers of the form xxx9.9xxx to 
round incorrectly. In these cases, a 9 was rounded to a colon(:). For example, 
printf ("%#13.6g",314109.968750) used to incorrectly output 31410: instead of 
314110. 

• The fscanf() function has been corrected to return the correct completion 
status value when the format string consisted of only whitespace. This 
affected applications which tested the return value of the function. 

• The fscanf() function now correctly returns -1 when positioned at the end of 
the file. The incorrect behavior was that the return status was being set to 
zero. 

• The fscanf() function now correctly recognizes the end-of-file condition when 
passed a format string that did not start with a percent sign. 

5.3.2.3 Process and Subprocess Problems Fixed 

V6.1 The following notes summarize fixes to process and subprocess problems: 

• The chdir() function has been corrected to permanently change the default 
directory when the program is executed in executive mode. The incorrect 
behavior was that the original default directory was restored when the 
program terminated. 

• The nice() function now ignores calls using an out of range value. 

• The nice() function now accepts priority values up to 63 which is compatible 
with POSIX priority values. 

• The RTL no longer access violates when trying to pass uninitialized 
environment data to a child process. 

• The function system() now correctly inherits the SYS$ERROR and 
SYS$OUTPUT of it’s parent when the parent is a batch job outputting to 
a log file. 

• Programs no longer receive an additional NULL argument when the program 
is run as a command (SET COMMAND image) as opposed to being run as a 
foreign command. Prior to this fix a program run as a command image would 
see an additional argument via argv/argc. 

• The sleep() function no longer is awakened by a pending $WAKE system 
service call. Prior to executing the $HIBER call for the sleep, pending $WAKE 
calls are flushed. 

• Wildcarded filespecs are no longer allowed in calls to access(), chmod(), and 
chown(). 

• The functions execvp() and execlp() now use the vaxc$path logical if defined 
by the user. 
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5.3.2.4 

V6.1 


5.3.2.5 

V6.1 


Error-Handling Problems Fixed 

The following notes summarize fixes to error-handling problems: 

• The function strerror() no longer requires the second argument be present if 
the first argument is EVMSERR. 

• The implementation of sigvec() has been changed to make the handler a 
permanent handler which need not be reset after the signal is posted. 

• A problem was fixed in the implementation of the longjmp() function that 
resulted in floating point registers F2 through F9 not being restored properly. 
This problem affects programs that directly call longjmp() as well as those 
that call system(), any of the exec*() routines or vfork(). The effect of this 
problem is that variables declared as float or double will not contain the same 
value after the call as before the call. 

• Invoking longjmp() from a signal handler that catches the SIGINT signal, 
where the SIGINT signal arrives while the file handle is in use, no longer 
leaves the file handle in use. Previously, all further I/O operations on that file 
would fail. 

• Applications calling VAXC$ESTABLISH can now link using the /NOSYSSHR 
qualifier. Prior releases caused problems due to the modularity of the DEC C 
RTL. 

• While the documentation indicates that signals are reset to SIG_DFL after 
they are caught, this is not entirely true for SIGINT. When the signal is 
raised a second time, the process exits with a status message instead of 
exiting quietly. A workaround is for the handler to explicitly set the signal to 
SIG_DFL. 

Miscellaneous Fixes 

The following notes summarize fixes to miscellaneous problems: 

• A table within the shareable image no longer requires alignment fixups 
at startup time. This table is now declared aligned and enhances the 
performance of initializing the image. 

• The sbrk() function has been corrected to return -1 when the process exceeds 
the pagefilequota. The incorrect behavior was that a successful status was 
being returned. 

• The exp() function now returns HUGE_VAL when an overflow condition is 
detected. 

• The DECC$DSTRTOD routine can now handle numbers larger than the 
D_FLOAT maximum but within the G_FLOAT maximum. This had been 
resulting in HPARITH, high-performance arithmetic trap, errors. 

• The _READ_GPR routine is no longer a global symbol of the RTL. 

• The sbrk() function no longer allocates one too many pages if the requested 
amount is an exact multiple of 512 bytes. 

• The universal symbol DECC$VAXC$GET_SDC is now part of the shareable 
image. 

• The return status from the delwin() function is now properly established. 

• The qsort() function no longer passes an incorrect address to one of its lower 
level routines, which resulted in an access violation. 
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5.3.3 Restriction 

V6.1 The RTL limits to 256 the number of simultaneously opened files. 

5.3.4 Problems 

V6.1 The following notes summarize problems with the C Run-Time Library: 

• Applications using the vfork and exec mechanisms to invoke parts of an 
application may notice that the parent seems to wait for the child process. 
This happens only when a child process is not cooperating in a mailbox 
exchange of file information between the parent and the child processes. 

This problem will be corrected in a future release of the OpenVMS operating 
system. 

• If an application program calls close() for STDOUT and then attempts to call 
the printf() function, an access violation may occur. 

• Repeatedly calling the system() function when only one process slot is left on 
the system may cause the RTL to go into an infinite loop. 

• The creat() function allows the programmer to create a variable-length record 
file with a record length of 65535. This is not a valid RMS record length 

for this file type. The programmer should avoid using both "rfm=var" and 
"mrs=65535" together. 

• Using "rop=noasy" in an open() call does not stop the RTL from using 
asynchronous I/O during write() operations. 

• The curses getch() function returns keypad characters as zero values instead 
of returning the SMG value of an integer. 

• Regular expressions in the source string passed to decc$to_vms do not work 
properly. The result is either an ACCVIO or a return value 0 (indicating that 
no files match the wildcard). 

5.4 DEC C and DEC C++ — Problem with SYS$LIB_C.TLB When 
Used with Lowercase 

V6.1 DEC C and DEC C++ users may encounter problems if they are calling functions 

defined in header files from SYS$STARLET_C.TLB or SYS$LIB_C.TLB and are 
using the /NAMES=AS_IS qualifier. 

Function prototypes defined in header files within SYS$STARLET_C.TLB and 
SYS$LIB_C.TLB define OpenVMS routine entry points. These entry points are 
externally defined using uppercase names. The function prototypes generated in 
the header files are only defined in lowercase. Normally, the compiler converts 
the names to uppercase for resolution by the linker. If the user compiles with 
the /NAMES=AS_IS qualifier, then this conversion does not happen and only the 
lowercase names are exported, resulting in a failure to locate these symbols at 
link time. 
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5.4 DEC C and DEC C++ — Problem with SYS$LIB_C.TLB When Used with Lowercase 


In the future, users will be able to use either the lowercase or uppercase 
names with header files from SYS$STARLET_C.TLB and SYS$LIB_C.TLB. The 
short-term fix for users calling any functions defined in these libraries and using 
the /NAMES=AS_IS qualifier is to generate the following code for the functions 
they are calling: 


#ifndef lower_case_function 

#define lower_case_function UPPER_CASE_FUNCTION 
#endif 


The following header files defined in SYS$LIB_C.TLB already contain the fix 
as stated previously. Users of functions within these header files will remain 
unaffected. 


acp_routines.h 

com_routines.h 

erl_routines.h 

exe_routines.h 


ioc_routines.h 

ldr_routines.h 

lnm_routines.h 

mmg_routines.h 


mt_routines.h 
pms_routines .h 
sch_routines.h 
smp_routines .h 


5.5 DEC C++ — Structures in SYS$LIB_C Need Prototypes 

V6.1 DEC C++ users who include header files from SYS$LIB_C.TLB may receive 

compiler errors. Many of the structures within SYS$LIB_C.TLB contain pointers 
to other structures. These pointers are defined using the tag name of the 
structure to which it points. In C, if you declare something using a tag name, it 
is not necessary to predefine it. DEC C++ requires that the name be predefined. 
If the header file you are including contains any pointers to structures, it will be 
necessary to create structure prototypes for them. 

As an example, the inclusion of a header file (header.h) that contained the 
following: 

typedef struct _structa { 
struct _structb *ptrl; 

struct _structc *ptr2; 

} STRUCTA; 

would require the following structure prototypes defined before the #include for 
the header file: 

struct _structb; 
struct _structc; 

#include <header.h> 


5.6 DEC COBOL Run-Time Library 

V6.1 The following is a list of changes in behavior for the DEC COBOL Run-Time 

Library (RTL) since the last CLD kit was released. For more information on CLD 
kits, refer to Section 7.6. For more information on new features and fixes in the 
DEC COBOL RTL, refer to the Version 2.0 DEC COBOL Compiler release notes. 
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5.6.1 Changes in ACCEPT and DISPLAY Behavior 

V6.1 If your application uses the Digital extensions to ACCEPT and DISPLAY, the 

following actions occur: 

• The cursor is moved to the upper left corner of the screen just prior to the 
execution of the first ACCEPT or DISPLAY statement. 

• The F10 function key is now treated as Ctrl/Z during all ANSI ACCEPT 
statements. 

• If your application displays a string that contains NULL characters (LOW- 
VALUES), the displayed value is no longer truncated. 

5.7 Debugging and Image Activation 

V6.1 Due to enhancements to the OpenVMS Debugger, the image activator has been 

modified to automatically activate SYS$SHARE:SYS$SSISHR.EXE when an 
image is debugged using the RUN/DEBUG command or linked with the /DEBUG 
qualifier. 

If the Delta/XDelta debugger is being used, SYS$SHARE:SYS$SSISHR.EXE may 
be automatically activated for you. The presence of this image should not alter 
your program’s correctness, but if your program is sensitive to virtual address 
layout or if for some reason SYS$SHARE:SYS$SSISHR.EXE is not installed 
properly on your system, you may want to bypass its automatic activation. 

To keep the image activator from activating SYS$SHARE:SYS$SSISHR.EXE for 
you, define the logical name SSI$AUTO_ACTIVATE to be "OFF" before running 
the program to be debugged with Delta/XDelta. 

5.8 OpenVMS Debugger 

V6.1 The following sections describe corrections, restrictions, and problems that are 

present in the OpenVMS Debugger. 

On AXP systems, the OpenVMS System-Code Debugger is available for debugging 
AXP operating system code. See the OpenVMS AXP Device Support: Developer's 
Guide for details on using the System-Code Debugger. 

The Delta/XDelta debugger (DELTA/XDELTA) is also available for debugging. 

See the OpenVMS Delta/XDelta Debugger Manual for details on using the 
Delta/XDelta debugger. 

5-8-1 Corrections 

V6.1 The following problems have been corrected in OpenVMS AXP Version 6.1: 

• In previous releases, an internal debugger error or access violation occurred 
when you issued a STEP/OVER command at a recursive call to the routine 
currently executing. 

• In previous releases, the debugger sometimes received an internal error 
during the processing of a SET IMAGE command for some large programs 
with many program sections (for example, a DEC Fortran routine with many 
COMMON blocks). 

• In previous releases, the debugger displayed incorrect instructions when you 
issued an EXAMINE/INSTRUCTION command for a routine. 
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5.8.2 

V6.1 

5.8.2.1 

V6.1 


5.8.2.2 

V6.1 


• In previous releases, the debugger did not compute symbol offsets correctly 
when the symbol to which an offset was applied was a routine, module, or 
image name. 

• In previous releases, the debugger did not support attempts to debug critical 
sections that were delimited by memory-locking (LDx_L) and memory¬ 
unlocking (STx_C) instructions. 

• In previous releases, if you set a breakpoint in an AST routine, and an 
AST fired during the execution of a STEP command, the STEP command 
incorrectly finished when the breakpoint in the AST routine triggered. When 
the AST routine finished and control returned to the point where the AST 
fired, the debugger reported an access violation at a random address. 

• In previous releases, when you issued a CALL command before another 
outstanding CALL command finished (that is, before the 'Value returned" 
message appeared), the debugger hung. 

• In previous releases, you could not pass parameters in the CALL command. 
This problem has been corrected, with the restriction that you still cannot 
pass floating-point parameters by value. 

• In previous releases, the first longword of a routine could not be examined. 

• In previous releases, when program execution was suspended in system space, 
the command EXAMINE PC displayed an incorrect value for the high-order 
longword of the PC. 

• In previous releases, if you issued an EXAMINE/PS command, the debugger 
returned a syntax error. 

Problems and Restrictions 

This section describes problems and restrictions that affect the debugger in 
OpenVMS AXP Version 6.1. For complete information on debugger functionality, 
see the OpenVMS Debugger Manual. 

Motif Version 1.1 Software Requirement 

If you have not installed a DECwindows Motif license (DW-MOTIF) on the 
node from which you are using the debugger, the debugger’s GUI fails with the 
following error messages: 

%N0NAME-W-N0MSG, Message number 00000000 

-DEBUG-F-FATALSTATUS, a fatal condition was detected by the debugger. 
%DEBUG-F--INITERR, an error has occurred during debugger initialization, 
unable to continue this session. 

To return to DCL level after this failure, enter a Ctrl/C or Ctrl/Y key sequence. To 
correct the problem, install a DECwindows Motif license, or use the character-cell 
interface by defining DBG$DECW$DISPLAY to " AA ". 

Image-Naming Restriction 

You cannot debug an image named DEBUG.EXE. This name is used internally 
for the kernel portion of the debugger. 

To work around this restriction, rename your image. 
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5.8.2.3 

V1.5 


5.8.2.4 

V1.5 

5.8.2.5 

V1.5 


5.8.2.6 

V1.5 


5.8.2.7 

V1.5 


CALL and SHOW CALLS Command Problems and Restrictions 

The following CALL command problems and restrictions appear in this release: 

• You cannot pass floating-point parameters by value in a CALL command. 

• After you issue a SHOW CALLS command, the output may include system 
call frames in addition to the user call frames associated with your program. 
System call frames appear in the following circumstances: 

— When an exception occurs 

— When an asynchronous system trap occurs 

— When a watchpoint occurs in system space 

The display of system call frames does not indicate a problem. 

EVALUATE Command Limitation 

When you issue the EVALUATE command for an integer, the debugger truncates 
the return value if it is larger than a longword. 

Integer Arguments to EXAMINE LABEL Command 

If you issue the command EXAMINE LABEL[ti] or EXAMINE LABEL(n), where 
LABEL is a label for a code location and n is an integer, an access violation error 
results. 

SET BREAK/UNALIGNED_DATA Command and Related System Service Call 

The SET BREAK/UNALIGNED_DATA command calls the SYS$START_ALIGN_ 
FAULT_REPORT system service routine. Do not issue this command if the 
program you are debugging includes a call to the same SYS$START_ALIGN_ 
FAULT_REPORT routine. If you issue the command before the program call, 
the program call fails. If the program call occurs before you issue the command, 
unaligned breaks are not set. 

Kept Debugger Restrictions and Problems 

The following problems or restrictions are specific to the Kept Debugger: 

• If a previous debugger process has not completely stopped, you may see the 
following error at debugger startup: 

%DEBUG-E-INTERR, internal debugger error in 
DBGMRPC\DBG$WAIT_FOR_EVENT got an ACK 

To fix this problem, exit the debugger. At DCL level, check to see whether 
any debugger subproceses exist by issuing the command SHOW PROCESS 
/SUBPROCESS. If any debugger subprocesses exist, you can stop them 
by using the DCL command STOP. You should then be able to restart the 
debugger without seeing the error described previously. 

• Ctrl/Y-DEBUG is not supported in the Kept Debugger configuration. 

• The RUN/COMMAND="command-line" capability does not use the command 
table of the process from which the debugger was invoked. When you append 
the /COMMAND qualifier to the RUN command, the following error displays: 

DBG> RUN/COMMAND="MY_COMMAND/MY_QUAL kit_build/copies=o" 

%DCL-W-IWERB, unrecognized command verb - check validity and spelling 
\MY_COMMAND\ 

To work around this problem, ask your system manager to build a custom 
DCLTABLES file for your project. Note that the DCLTABLES file must be 
updated if you change the DCL command. 
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5.8.2.8 

V1.5 


• When you run a sequence of many large programs, the debugger might fail 
due to exhaustion of memory, global sections, or some other resource. 

To fix this problem, exit the debugger and restart the debugging session. 

• Many commands are disabled when there is no running program. This 
includes commands that might be expected to work, such as SET STEP and 
SET PROMPT/SUFFIX. The disabled command may cause DBG$INIT files 
to generate %DEBUG-W-NOPROGRAM messages. These commands are 
enabled once a RUN command has been executed. 

• The prompt may change when a RUN command is executed. It will change 
back to its former state once the program has finished. 

• If you are using the Motif interface (as opposed to character-cell screen mode), 
and you try to run a program that does not exist or misspell the name of a 
program that does exist, you may not notice the following error messages: 

%DCL-W-ACTIMAGE, error activating image 
-CLI-E-IMAGEFNF, image file not found 

This is because Motif displays the messages in the DECterm window, rather 
than in the Command View. Therefore, it is not always obvious that an error 
has occurred. 

To avoid this problem, make sure the “Select an application to run” box in the 
File Selection pop-up menu contains a valid file specification. 

• The %DEBUG-I-INITIAL message is not displayed after execution of the 
RERUN/SAVE command. The absence of this message does not adversely 
affect the execution of this command. 

• The Kept Debugger shares I/O channels with the parent process when it is 
run via a SPAWN/NO WAIT command. Therefore, you must press the Return 
key twice on the DECterm window from which the debugger was run after 
the debugger version number has appeared in the Source window. 

Optionally, you can execute the Kept Debugger in the following manner: 

$ DEFINE DBG$INPUT NL: 

$ SPAWN/NOWAIT RUN SYS$SHARE:DEBUGSHR.EXE 

• If you issue the RERUN command while your file is locked by another user, 
the debugger returns the following message: 

%DEBUG-E-NORERUNPGM, There is no program to RERUN 

To work around this problem, wait until your file is unlocked. Then, issue a 
RUN command and reset breakpoints. 

• If you use the DCL SET COMMAND to define a local flavor of a command, 
the debugger will not find the new, local flavor of the command. 

DECwindows Motif Interface Restrictions and Problems 

The following problems or restrictions are specific to the DECwindows Motif 
interface: 

• Occasionally, if you are debugging a UI application and you have many 
debugger windows overlapping the user program’s windows, the X server will 
abruptly terminate the user program. 

To avoid this problem, refrain from overlapping or covering windows belonging 
to the user program. 
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• If you are stopped at a breakpoint in a routine that has control of the mouse 
pointer via a PointerGrab or a KeyboardGrab, your workstation will hang. 

To work around this problem, debug your program using two workstations. 
For more information, see the OpenVMS Debugger Manual. 

• Occasionally, if you are scrolling or clicking on items in the Register View, the 
following message displays in the DECterm window from which you initiated 
the debugging session: 

X Toolkit Warning: Not all children have same parent 
in XUnmanageChildren 

You can ignore this message. 

• Initially, the debugger main and optional views windows in this version may 
appear to be oddly sized. The resource file shipped with the Version 1.5 
debugger causes these windows to take the shape of the previous source and 
control windows in Version 1.5. 

To work around this problem, resize the new windows and save your window 
configuration. 

• If you attempt to typecast or change the radix for a monitored item (for 
example, a task in a multitasking program) where deposit operations do not 
make sense, the debugger does not issue an error message. Instead, it tries to 
complete the operation and then freezes the display. 

To work around this problem, exit the debugger by issuing a Ctrl/Y key 
sequence from the DECterm window in which you invoked the debugger. 

• Table 5-1 lists debugger commands that are disabled in the DECwindows 
Motif interface. The debugger issues an error message if you try to enter any 
of these disabled commands at the command prompt or when the debugger 
executes a command procedure containing any of these commands. 


Table 5-1 Debugger Commands Disabled in the DECwindows Motif Interface 


ATTACH 

SELECT 

CANCEL MODE 

(SET,SHOW) ABORTJKEY 

CANCEL WINDOW 

(SET,SHOW) KEY 

DEFINE/KEY 

(SET,SHOW) MARGINS 

DELETE/KEY 

SET MODE [NOJKEYPAD 

DISPLAY 

SET MODE [NOJSCREEN 

EXAMINE/SOURCE 

SET MODE [NO]SCREEN_LOG 

EXPAND 

SET MODE [NOJSCROLL 

EXTRACT 

SET OUTPUT [NOJTERMINAL 

HELP 

(SET,SHOW) TERMINAL 

MOVE 

(SET,SHOW) WINDOW 

SAVE 

(SHOW,CANCEL) DISPLAY 

SCROLL 

SHOW SELECT 


• Motif does not provide for specialized key support (such as Ctrl/Y), but the 
Motif interface provides alternative means of executing these functions (for 
example, the STOP button). Therefore, commands that require specialized 
key support are disabled in the Motif interface. 
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5.8.2.9 

V1.0 


5.8.2.10 

V1.0 

5.8.2.11 

V1.0 


5.8.2.12 

V1.0 


5.8.2.13 

V1.0 


• Commands related to the keypad or key bindings in the graphical user 
interface differ from those used in the command interface. See the OpenVMS 
AXP Version 6.1 New Features Manual for more information. 

• Commands related to character-cell terminal displays apply only to the 
command interface. These commands are disabled in the Motif interface. 

• The Motif interface to the debugger does not make use of a DECterm window. 
Therefore, commands that require a DECterm window are disabled in the 
Motif interface. The exception is the EDIT command, which is still available. 

• If you decrease the size of the Communications pane so that the prompt 
is occluded, the message area is not automatically scrolled to display the 
prompt. 

To work around this problem, use the vertical scroll bar to scroll the view so 
that the prompt reappears. 

• Under certain circumstances, when the Breakpoint View option is invoked 
prior to setting a breakpoint, the Breakpoint View has a height of zero. 

To work around this problem, resize the Breakpoint View after it has been 
displayed and then resave its location. 

• The column labels within the Monitor View and Tasking View do not line up 
properly when resizing the Monitor View. 

Debugging Translated Images 

The debugger does not support attempts to debug translated images. If you must 
debug a translated image, use the Delta/XDelta Debugger. For more information 
on this debugger, see the OpenVMS Delta/XDelta Debugger Manual. 

Debugging Sliced Images 

The debugger does not support attempts to debug sliced images (also called 
installed resident images). 

Debugging Inlined Routines 

The debugger does not support attempts to debug inlined routines. If you attempt 
to debug an inlined routine, the debugger issues a message that it cannot access 
the routine, as shown in the following example: 

%DEBUG-E-ACCESSR, no read access to address 00000000 

To work around this problem, compile your program with the /NOOPTIMIZE 
qualifier. 

Debugging Global Sections 

The debugger does not support setting watchpoints on variables whose addresses 
are in global sections. If you attempt to set a watchpoint on a location in a global 
section, the debugger issues a message rejecting the watchpoint, as shown in the 
following example: 

%DEBUG-E-BADWATCH, cannot watch protect address 'address-value' 

Debugging Register Frame Procedures or Null Frame Procedures 

The debugger does not fully support attempts to debug register frame procedures 
or null frame procedures. If you issue the STEP/OVER or STEP/RETURN 
commands for these procedures, unexpected results might occur. For more 
information on register frame procedures and null frame procedures, see the 
OpenVMS Calling Standard. 
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5.8.2.14 

V1.0 


5.8.2.15 

V1.0 


5.8.2.16 

V1.0 


5.8.2.17 

V1.0 


5.8.2.18 

V1.0 


5.8.2.19 

VI.0 


Complex Variables in FORTRAN Programs 

The debugger cannot evaluate expressions that contain complex variables. 
(Currently, DEC Fortran is the only supported language that provides complex 
variables.) To work around this problem, examine the complex variable and then 
evaluate the expression using the real and imaginary parts of the expression 
obtained from the EXAMINE command. 

Concealed Rooted-Directory Logical Names for Source Files 

If you use a rooted-directory logical name to specify the location of a source file 
when compiling a program with the /DEBUG qualifier, make sure that the rooted- 
directory logical name is concealed. You must include the /TRANSLATION. 
ATTRIB=CONCEALED qualifier in your logical name definition, as follows: 

DEFINE /TRANSLATION_ATTRIB=CONCEALED 
root_dir_log_name disk:[dir.] 

If the rooted-directory logical name is not concealed and you move the source file 
to another directory after compilation, you are unable to use the debugger SET 
SOURCE command to specify the new location of the source file. 

DEPOSIT/TYPE Command with C Programs 

When debugging a C program, you cannot use the DEPOSIT/TYPE command 
if the type specified is a mixed- or lowercase name. For example, suppose the 
program has a function like the following: 

xyzzy_type foo () 

{ 

xyzzy_type z; 
z = get_z (); 
return (z); 

} 

If you try to enter the following command, the debugger issues a message that it 
cannot find the type “xyzzy.type”: 

DBG> DEPOSIT/TYPE=(xyzzy_type) z="whatever" 

SHOW BREAK and SHOW TRACE Command Limitations 

SHOW BREAK and SHOW TRACE do not display individual instructions when 
the break or trace is on a particular class of instruction (such as SET BREAK 
/CALL or SET BREAK/RETURN). 

STEP/INTO Command and User Exception Handlers 

When execution is stopped at an exception break, STEP/INTO does not transfer 
control to a user exception handler. To work around this problem, set a 
breakpoint on the handler. 

STEP/OVER Command Error with One-Line Program Loops 

When you issue the STEP/OVER command at a program loop that is coded on a 
single source line, and that source line also contains a routine call, the debugger 
steps into the called routine instead of stepping to the next source line. In the 
following example, if you issue the STEP/OVER command when execution is 
stopped at the FOR loop, the debugger steps into the square routine instead of 
stepping to the j assignment statement: 

for (i=0;i<10;i++) square(i); 

j=6; 
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To work around this problem, either set a temporary breakpoint on the line 
following the FOR loop (in the previous example, j=6), or move the routine call to 
a separate line, as follows: 

for (i=0;i<10;i++) 
square(i); 

5.8.2.20 $HIBER Call Causing User Applications to Hibernate 

VI.0 A user application remains in HIB (hibernate) state: 

• If a program, running under the two-process or multiprocess debugger, issues 
a $WAKE call followed by a $HIBER call, the user application hibernates. 

• If you step inside or interrupt RTL or system services routines that make 
use of $WAKE or $HIBER, for example, Lib$wait or sys$schdwk, the user 
application hibernates. 

• When an application includes the LCK$M_DEQALL modifier in a $DEQ 
system service call, this modifier breaks communication links between the 
portion of the debugger in the user process (the kernel) and the debugger 
main process. The result is that the user’s process stays in hibernate (HIB) 
state. 

To work around this problem, debug these application programs using the 
limited one-process mode, rather than the default or the multiprocess mode. 
To set up one-process mode, issue the following command: 

$ DEFINE DBG$PR0CESS NONE 

DCL ANALYZE/PROCESS_DUMP Command and Zero Program Counter 

The debugger cannot analyze a process dump file if the dump describes an 
exception where the program counter (PC) is zero. 

STEP Command into System Service Calls 

If you attempt to single-step into a system service call, an access violation 
can result if prior to your debugging session, you turned on system service 
interception with one of the following statements: 

$ DEFINE SSI$AUTO_ACTIVATE ON 
$ DEASSIGN SSI$AUT0_ACTIVATE 

To work around this problem, turn off system service interception with the 
following statement: 

$ DEFINE SSI$AUTO_ACTIVATE OFF 

5.9 DECmigrate 

VI.5 DECmigrate Version 1.1 software generates translated images that are executable 

on OpenVMS AXP Version 1.5 or later. This version of DECmigrate does not 
support OpenVMS AXP Version 1.0. Images translated by DECmigrate Version 
1.0 are executable on all versions of the OpenVMS AXP system. 

5.10 DECthreads 

The following sections pertain to DECthreads. 


5.8.2.21 

V1.0 

5.8.2.22 

V1.0 
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5.10.1 Exit Handler Routines 

V6.1 If you try to abort a program that uses DECthreads functions in an exit handler 

routine by using a Ctrl/Y sequence followed by the DCL EXIT command (or 
almost any DCL command), the program may hang indefinitely in the exit 
handler routine. 

One instance of this problem occurs when you type a Ctrl/Y sequence to interrupt 
a multithreaded program in the middle of a C RTL I/O function. The problem is 
with the operating system, not with your program code or the C RTL code. To 
release your program from the exit handler routine, type another Ctrl/Y sequence 
followed by the DCL STOP command. 

Digital expects to correct this problem in a subsequent release of the OpenVMS 
operating system. 

5.10.2 DEC C RTL Problem 

VI.5 A potential problem occurs between the DECthreads software and the DEC C 

RTL when a C program that calls LIB$FIND_IMAGE_SYMBOL dynamically 
activates DECthreads or another shareable image that depends on DECthreads. 
This problem may result in an access violation inside CMA$RTL in a call from 
DECC$SHR. 

To work around this problem, link the image that calls LIB$FIND_IMAGE_ 
SYMBOL against CMA$RTL. 

Dynamically activating DECthreads or shareable images that depend on 
DECthreads does not work under all circumstances. Several software facilities 
contain code whose behavior is conditional upon the presence or absence of 
threads at the time that these facilities are initialized. If any of these facilities 
are in use by a program, threads cannot be safely brought into the process 
after execution begins because these facilities cannot respond to the change. An 
attempt to bring threads in at this stage typically causes the program to abort. 
Other unpredictable behavior, such as access violations, may result instead of 
program termination. 

5.10.3 Routines Can Terminate Process 

VI.0 The DECthreads routines cma_thread_exit_error, cma_thread_exit_normal, 

and pthread_exit should terminate the calling thread only. However, these 
routines erroneously cause the process to terminate when they are called in the 
initial thread. 

This problem will be corrected in a future version of OpenVMS AXP. 

The Guide to DECthreads provides additional detailed information about using 
DECthreads software. 

5.11 Device Support on OpenVMS AXP 

V6.1 The following sections contain notes about OpenVMS AXP device drivers. 
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5.11.1 

V6.1 


5.11.2 

V6.1 


New Device Driver Interface 

OpenVMS AXP Version 6.1 supports user-written device drivers and a new 
device driver interface known as the Step 2 driver interface, which replaces the 
temporary Step 1 driver interface that was provided in OpenVMS AXP Versions 
1.0 and 1.5. The Step 2 driver interface provides support for writing device 
drivers in the C programming language or another high-level language and that 
can conform to the OpenVMS AXP calling standard. An example device driver 
written in C is provided in the SYS$EXAMPLES directory. 

The following AXP device support manuals are available for OpenVMS AXP 
Version 6.1: 

• Creating an OpenVMS AXP Step 2 Device Driver from a Step 1 Device Driver 

This manual describes how to convert an OpenVMS AXP Step 1 device driver, 
written in VAX MACRO, to an OpenVMS AXP Step 2 device driver, also 
written in VAX MACRO. 

• Creating an OpenVMS AXP Step 2 Device Driver from an OpenVMS VAX 
Device Driver 

This manual describes how to convert an OpenVMS VAX device driver, 
written in VAX MACRO, to an OpenVMS AXP Step 2 device driver, also 
written in VAX MACRO. 

• OpenVMS AXP Device Support: Developer's Guide 

This manual describes how to write an OpenVMS AXP device driver in a 
high-level language. 

• OpenVMS AXP Device Support: Reference 

This manual provides reference material for creating OpenVMS AXP device 
drivers, and it describes the macros, system routines, and entry points used 
in converting OpenVMS VAX and Step 1 OpenVMS AXP device drivers to 
Step 2 OpenVMS AXP device drivers. 

Step 1 Drivers Are Obsolete 

OpenVMS AXP Version 6.1 does not support Step 1 driver interfaces, and 
source changes are required to convert a Step 1 driver to a Step 2 driver. For 
detailed information about how to convert a Step 1 driver to a Step 2 driver, see 
Creating an OpenVMS AXP Step 2 Device Driver from a Step 1 Device Driver and 
OpenVMS AXP Device Support: Reference. 

If you attempt to load a Step 1 driver that was compiled and linked on 
any previous version of the OpenVMS AXP operating system, the System 
Management utility (SYSMAN) will issue the following warning message, and the 
driver will not be loaded: 

$ mcr sysman io connect myaO/noadapter/driver=$users:[jones]mydriver_vl5 
%SYSMAN-I-N0DERR, error returned from node BEAMME 
-SYSTEM-W-SYSVERDIF, system version mismatch; please relink 

If you attempt to relink a Step 1 driver object module that was compiled on any 
previous version of the OpenVMS AXP operating system, the linker will issue 
warning messages about undefined symbols for any references to the obsolete 
Step 1 support routines. The resultant image file is not loadable. 
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If you attempt to recompile a Step 1 driver module, the MACRO-32 Compiler will 
issue many compilation warnings and errors, including the following messages: 

%AMAC-E-GENERROR, (1) generated ERROR: 0 DPTAB must declare driver STEP=2 ; 


%AMAC-E-GENERROR, (1) generated ERROR: 0 FUNCTAB is an obsolete macro used 
by STEP=1 drivers; 


No object module will be produced. 


5.11.3 Step 2 Drivers Developed Using Field-Test Versions 

V6.1 You must recompile and relink any Step 2 driver that was compiled and linked 

on OpenVMS AXP T2.0-FT3 or an earlier field-test version to load it successfully 
on OpenVMS AXP Version 6.1. If you attempt to load a Step 2 driver that was 
compiled and linked on OpenVMS T2.0-FT3, SYSMAN will issue the following 
warning message, and the driver will not be loaded: 

$ mcr sysman io connect myaO/noadapter/driver=$users:[jones]mydriver_vl5 
%SYSMAN-I-NODERR, error returned from node BEAMME 
-SYSTEM-F-DRVNOTVALID, device driver failed DPT consistency checks 

Drivers that were compiled and linked on OpenVMS T6.1-FT4 do not require 
recompilation or relinking. These drivers can be loaded on OpenVMS AXP 
Version 6.1. 


5.11.4 Obsolete Step 1 Driver Support Routines 



V6.1 



The Step 1 JSB-Based Routines listed in this section are now obsolete. For 
information about the Step 2 routines that replace them, see Creating an 
OpenVMS AXP Step 2 Device Driver from a Step 1 Device Driver. 


ACP$ACCESS 

ACP$ACCESSNET 

ACP$DEACCESS 

ACP$MODIFY 

ACP$MOUNT 

ACP$READBLK 

ACP$WRITEBLK 

COM$SETATTNAST 

COM$SETCTRLAST 

EXE$ABORTIO 

EXE$FINISHIO 

EXE$FINISHIOC 

EXE$IORSNWAIT 

EXE$KP_STARTIO 

EXE$LCLDSKVALID 

EXE$MODIFY 

EXE$MODIFYLOCK 

EXE$MODIFYLOCK_ERR 

EXE$ONEPARM 

EXE$QIOACPPKT 

EXE$QIODRVPKT 

EXE$QIORETURN 

EXE$READ 

EXE$READCHK 

EXE$READCHKR 

EXE$READLOCK 

EXE$READLOCK_ERR 

EXE$SENSEMODE 
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EXE$SETCHAR 

EXE$SETMODE 

EXE$WRITE 

EXE$WRITECHK 

EXE$WRITECHKR 

EXE$WRITELOCK 

EXE$WRITELOCK_ERR 

EXE$ZEROPARM 

IOC$CLONE_UCB 

IOC$LINK_UCB 

MT$CHECK_ACCESS 

5.11.5 Obsolete Data Structure Cells 

V6.1 Some DDT and DPT data structure fields that supported Step 1 device drivers 

have been removed in OpenVMS AXP Version 6.1. Table 5—2 lists the obsolete 
Step 1 fields and the Step 2 fields that have similar functions. 

Note that the Step 2 cells use different names because they point to routines 
whose interfaces are different or they point to data structures whose layout is 
significantly altered. For this reason, do not replace each reference to an obsolete 
Step 1 field with its corresponding Step 2 field without taking into account the 
routine interface and data structure changes. 


Table 5-2 Obsolete Data Structure Cells 

Obsolete Step 1 Field Similar Step 2 Field 


DDT$L_ALTSTART 

DDT$PS_ALTSTART 

DDT$L_CANCEL 

DDT$PS_CANCEL 

DDT$L_CANCEL_SELECTIVE 

DDT$PS_CANCEL_SELECTIVE 

DDT$L_CHANNEL_ASSIGN 

DDT$PS_CHANNEL_ASSIGN 

DDT$L_CLONEDUCB 

DDT$PS_CLONEDUCB 

DDT$L_CTRLINIT 

DDT$PS_CTRLINIT 

DDT$L_FDT 

DDT$PS_FDT 

DDT$L_MNTVER 

DDT$PS_MNTVER 

DDT$L_REGDUMP 

DDT$PS_REGDUMP 


DDT$PS_ALTSTART_2 or DDT$PS_ 
ALTSTART_J SB 

DDT$PS_ALTSTART_2 or DDT$PS_ 
ALTSTARTJSB 

DDT$PS_C AN CE L_2 

DDT$PS_C AN CE L_2 

DDT$PS_CANCEL_SELECTIVE_2 

DDT$PS_CANCEL_SELECTIVE_2 

DDT$PS_CHANNEL_ASSIGN_2 

DDT$PS_CHANNEL_ASSIGN_2 

DDT$PS_CLONEDUCB_2 

DDT$PS_CLONEDUCB_2 

DDT$PS_CTRLINIT_2 

DDT$PS_CTRLINIT_2 

DDT$PS_FDT_2 

DDT$PS_FDT_2 

DDT$PS_MNTVER_2 

DDT$PS_MNTVER_2 

DDT$PS_REGDUMP_2 

DDT$PS_REGDUMP_2 

(continued on next page) 
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5.11.6 

V6.1 


5.11.7 

V6.1 


Table 5-2 (Cont.) Obsolete Data Structure Cells 


Obsolete Step 1 Field 

Similar Step 2 Field 

DDT$L_START 

DDT$PS START 2 or DDT$PS 
STARTJSB 

DDT$PS_START 

DDT$PS START 2 or DDT$PS 
START_JSB 

DDT$L_UNITINIT 

DDT$PS_UNITINIT_2 

DDT$PS_UNITINIT 

DDT$PS_UNITINIT_2 

DPT$PS_DELIVER 

DPT$PS_DELIVER_2 


Device Timeout Routine Address 

OpenVMS AXP Version 6.1 includes a change to the handling of device interrupt 
timeouts. Prior to this release, the UCB$L_FPC cell in the device unit control 
block (UCB) contained the procedure value of the routine that served as both 
the resume from interrupt routine and the interrupt timeout routine. These 
routines are now separate. The new UCB cell UCB$PS_TOUTROUT is used for 
the procedure value of the interrupt timeout routine. 

These changes are transparent to code that uses the WFIKPCH or WFIRLCH 
macros, or calls the IOC$PRIMITIVE_WFIKPCH or IOC$PRIMITIVE_WFIRLCH 
routines. 

However, code that manually sets the UCB$V_TIM bit in the UCB$L_STS 
will now need to place the timeout routine procedure value into the UCB$PS_ 
TOUTROUT cell instead of the UCB$L_FPC cell. For more information, see 
Creating an OpenVMS AXP Step 2 Device Driver from a Step 1 Device Driver and 
OpenVMS AXP Device Support: Reference. 

Restriction on Passing C Structure Member Names to Nested C Macros 

The file SYS$LIBRARY:SYS$LIB_C.TLB is a library of C header files that 
define structures corresponding to the structures defined for MACRO-32 in 
SYS$LIBRARY:LIB.MLB. These C structure definitions also include simple 
macros, which allow the use of the same field names in drivers written in C as 
those used in drivers written in MACRO-32 and Bliss. 

A compile-time error results if both of the following occur: 

• You pass one of these simple macro names for a structure member as part of 
a parameter to a C macro 

• This macro passes this parameter to another macro 

You can avoid this problem by using one of the following methods: 

• “Flattening” the macro definition (by expanding the nested macros) 

• Using C inline functions to replace the nested macros while maintaining the 
desired modularity 

• Introducing additional temporary storage in the outer macro to avoid passing 
the input arguments directly to the nested macros 
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5.11.8 Interface Change to IOC$CRAM_CMD System Routine 

V6.1 The Step 1 IOC$CRAM_CMD routine interface, which is described in Creating a 

Step 1 Driver from an OpenVMS VAX Device Driver, is as follows: 

status = ioc$cram_cmd (cmd_index, 

byte_offset, 

ADP, 

CRAM, 

[buffer_ptr]); 

Inputs: 

cmd_index Unsigned longword. 

byte_offset Unsigned longword. 

adp Signed longword. Address of ADP. 

cram Signed longword. Address of CRAM. 

buffer_ptr Signed longword. Optional. Address of buffer, 

2 quadwords in length. 

Outputs: 

SS$_NORMAL success, CRAM successfully initialized 
SS$_BADPARAM failure. Bad input argument. 

The optional buffer_ptr argument has been removed. OpenVMS AXP Version 6.1 
contains a new argument called the IOHANDLE, which is a magic number 
supplied by a platform-independent I/O bus mapping routine. When the 
IOHANDLE argument is present, IOC$CRAM_CMD will use the IOHANDLE to 
do its address calculations. 

The new IOC$CRAM_CMD interface for OpenVMS AXP Version 6.1 is as follows: 

status = ioc$cram_cmd (cmd_index, 

byte_offset, 

ADP, 

CRAM, 

[IOHANDLE]); 


Inputs: 

cmd_index Unsigned longword. 

byte_offset Unsigned longword. 

adp Signed longword. Address of ADP. 

cram Signed longword. Address of CRAM, 

iohandle Quadword I/O handle passed by reference. 

The I/O handle is a magic number returned by the 
platform-independent bus mapping routines. 

Outputs: 

SS$_NORMAL success, CRAM successfully initialized 
SS$_BADPARAM failure. Bad input argument. 

If you are currently calling IOC$CRAM_CMD with 4 input arguments, you do not 
have to make any changes. If you are calling IOC$CRAM_CMD with 5 arguments 
and the 5th argument is a zero, you do not have to make any changes. If you 
are currently calling IOC$CRAM_CMD with 5 arguments with a nonzero 5th 
argument, you will have to make a change to eliminate the buffer_ptr argument. 

For more information about the IOC$CRAM_CMD routine, see OpenVMS AXP 
Device Support: Reference. 
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5.11.9 New Bus Support Routines for I/O Bus Device Access 

V6.1 OpenVMS AXP Version 6.1 contains the following new platform-independent 

mapping and access routines: 

• IOC$MAP_IO 

• IOC$READ_IO 

• IOC$WRITE_IO 

• IOC$UNMAP_IO 

The IOC$MAP_IO routine maps I/O bus physical address space into an address 
region accessible by the processor. The IOC$UNMAP_IO routine is provided to 
unmap a previously mapped space, returning the IOHANDLE and the PTEs to 
the system. IOC$READ_IO and IOC$WRITE_IO are platform-independent I/O 
access routines that provide a platform-independent way to read and write I/O 
space without the overhead of CRAM allocation and initialization. These routines 
require that the I/O space to be accessed has been previously mapped by a call to 
IOC$MAP_IO. For more information about these routines, see the OpenVMS AXP 
Device Support: Developer's Guide. 

5.12 Source-Level Debugging Support for Device Drivers 

V6.1 OpenVMS AXP Version 6.1 supports a new programming tool that can be 

used to debug nonpageable system code and device drivers running at any 
IPL. The OpenVMS AXP System-Code Debugger (system-code debugger) lets 
you use the OpenVMS Debugger interface to observe and manipulate system 
code interactively as it executes. For more information about how to use the 
system-code debugger, see the OpenVMS AXP Device Support: Developer's Guide. 

Before using the system-code debugger, note the following known problems and 
limitations: 

• The CALL command is not currently implemented. 

• If you use the SET WATCH command, it uses nonstatic watchpoints. Because 
nonstatic watchpoints are slower than static watchpoints, their use is not 
recommended. 

• With the OpenVMS Debugger, if you use the SET BREAK/EXCEPTION 
command, when the program hits an exception, the user could fix the 
problem and continue the program. With the system-code debugger, the 
SET BREAK/EXCEPTION command catches the problem later (just before a 
bugcheck). Therefore, it is not possible to fix the problem and proceed. The 
GO command will let the system bugcheck and write the crash dump. 

• Setting breakpoints at IF statements in the C programming language does 
not always work. For example, if you have code like the following and you set 
a breakpoint at the first line, the system-code debugger may or may not hit 
the breakpoint (depending on the condition): 

if (x) 

{ 

} else 
{ 

} 
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5.13 


5.13.1 

V1.5 


5.13.2 

vi.o 


To avoid this problem, you can set two breakpoints, one in the THEN clause 
and one in the ELSE clause, or set a breakpoint before the IF statement and 
then single-step until you reach the IF statement. 

• When using the SET MODULE command on some images with the system- 
code debugger, you may receive an error message similar to the following: 

%DEBUG-E-INVPD, procedure descriptor at 00028840 is not valid. 

This procedure descriptor is either in the init section for the image or in a 
paged-out image section. You can determine this by searching for the above 
value in the MAP file for the image to which the module belongs. 

If the value is not within the init image section or a pageable section, file a 
Problem Report and provide the error message along with the MAP file for 
the image. 

Executive Notes 

The following sections provide information about the executive for OpenVMS 
AXP. 

New Condition Code for Cross-Mode Page-Read Errors 

OpenVMS has historically treated as a special case those page-read errors that 
occur for a page owned by user or supervisor mode (outer mode) but accessed 
from executive or kernel mode (inner mode) at the time of the page fault. In this 
case, the page that incurs a page-read error would be zeroed, the protection of the 
page would be set to Exec Write (thereby allowing no access to supervisor or user 
modes), and the process would be allowed to continue referencing this page. No 
condition code would be signaled to the process. 

The intent of this algorithm is to prevent a system failure that would occur 
when a system service (executing in inner mode) accesses a page that is not in 
the working set and that cannot be read from the paging disk. This algorithm 
assumes that the process will return to user mode and that any subsequent 
attempt to access the page will result in an access violation, which causes the 
process to abort. In most cases, this assumption is valid. 

However, in some cases, the program continues to access (from inner mode) data 
in pages that were originally created in outer mode. No access violation occurs as 
the algorithm above expects. The “hidden” zeroing of pages for which page-read 
errors occur can lead to eventual undetected corruption of the volatile network 
database as the page of zeroes continues being processed. 

This behavior has changed in Version 1.5. Instead of zeroing the affected page, 
the new condition SS$_PAGRDERRXM (page-read error across access modes) is 
signaled. If no established handler fields this exception, the system’s last-chance 
handler aborts (deletes) the process. 

Spinlock Changes 

The rank values for all current static spin locks have been spread out to allow for 
future additions. 

All known references to the JIB dynamic spin lock have been replaced with 
interlocked code sequences, allowing the spin lock itself to be eliminated. 
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5.14 File System Notes 

The following sections provide information about file system support in this 
release of OpenVMS AXP. All basic disk file system support is present in 
OpenVMS AXP. 

5.14.1 Restriction 

VI.5 ODS-1 format disks are not supported on OpenVMS AXP. 

5.14.2 File Definition Language 

V1.0 The File Definition Language (FDL) facility is included in this version of 

OpenVMS AXP. FDL provides FDLSHR.EXE and CREATEFDL.EXE, the latter 
invoked with CREATE/FDL. 

In addition, OpenVMS AXP includes the Edit/FDL (EDIT/FDL) utility. You can 
use EDIT/FDL to create new files, but you may not be able to edit existing files. 

5.14.3 National Character Set 

VI.0 The National character set (NCS) runs as a native AXP image. All user-visible 

functions and interfaces of NCS are identical to OpenVMS VAX NCS. An NCS 
library created on a VAX system is supported on an AXP system. 

Fortran Run-Time Library 

The following notes pertain to the DEC Fortran Run-Time Library (RTL). 

Fortran RTL Bug Fixes 

The two bug fixes available in ECO kit AXPFORT01_015 are included in this 
release. 

5.15.2 DEC Fortran RTL Changes in Behavior 

V6.1 The following are changes in behavior for the DEC Fortran RTL. 

5.15.2.1 New Open File Limit 

V6.1 The limit on open files has been increased from approximately 200 to 

approximately 600. 

5.15.2.2 LIST-DIRECTED Floating-Point Output Format Changes 

V6.1 When compiled in /FLOAT=IEEE mode, the formats used for LIST-DIRECTED 

output of REAL*8 and COMPLEX*8 variables have changed to comply with 
ANSI X3.9-1978, the Fortran ’77 language standard. The previous format was 
1PG24.16 for REAL*8 and 1PG23.16 for COMPLEX* 16. The new formats are 
1PG24.15E3 for REAL*8 and 1PG23.15E3 for COMPLEX*16. 

Formatted Floating-Point Output Format Changes 

To comply with ANSI X3.9-1978, output using formats of the form Ew.d, Gw.d, 
and Dw.d has been changed to suppress the letter "E" in the output when the 
number of exponent digits exceeds 2. 


5.15.2.3 

V6.1 


5.15 DEC 
5.15.1 DEC 

V6.1 
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5.16 Full IEEE Floating-Point Support Available 

V6.1 OpenVMS AXP Version 6.1 provides support for IEEE Standard for Binary 

Floating-Point Arithmetic (IEEE Std 754-1985). The OpenVMS AXP IEEE 
floating-point support provides the following features: 

• Support for IEEE trap behavior 

IEEE Standard 765-1985 specifies five types of exceptions (Invalid Operation, 
Division by Zero, Overflow, Underflow, and Inexact), and the behavior when 
such exceptions occur. IEEE Standard 765-1985 also specifies that the user 
should be able to request a trap on any of the five exceptions by specifying a 
handler for it. 

OpenVMS AXP Version 6.1 provides support that is compliant with the IEEE 
trap behavior. 

• Support for IEEE non-finite arithmetic 

The Alpha architecture supports non-finite IEEE arithmetic operations 
(involving infinity operands, Nans, and denormals) by reporting an arithmetic 
trap. The Alpha architecture specifies that a software completion handler 
interposed between the hardware and the user application will provide the 
correct behavior. 

OpenVMS AXP Version 6.1 includes an IEEE completion handler that 
emulates the IEEE non-finite arithmetic operations in software. 

For more information on IEE floating-point support, see the OpenVMS 
Programming Concepts Manual. 

Image Activator Length Comparison Problem Fixed 

In rare circumstances prior to OpenVMS AXP Version 6.1, you could build a 
correct image with the OpenVMS linker and receive the following error message 
when you tried to run the image: 

IMGACT-F-BAD_FIXUPVEC, the fixup vector contains inconsistent data 

The message occurred because a length comparison in the image activator was 
off by 1 byte. The failure happened when the necessary fixup information exactly 
filled the area of the image allocated for that purpose. 

This problem has been fixed in OpenVMS AXP Version 6.1. 

5.18 Effects of a Failure During an I/O Write Operation 

VI.5 The operating system ensures that when an I/O write operation returns a 

successful completion status, the data is available on the disk or tape media. 
Applications that must guarantee the successful completion of a write operation 
can verify that the data is on the media by specifying the data check function 
modifier IO$M_DATACHECK, which is described in the OpenVMS I/O User's 
Reference Manual. Note that the IO$M_DATACHECK data check function, which 
compares the data in memory with the data on disk, affects performance because 
the function incurs the overhead of an additional read operation to the media. 

If a system failure occurs while a multiple-block write operation is in progress, 
the operating system does not guarantee the successful completion of the write 


5.17 

V6.1 
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operation. (OpenVMS does guarantee single-block write operations to DSA drives.) When a 
failure interrupts a write operation, the data may be left in any one of the following conditions: 

• The new data is written completely to the disk blocks on the media, but a 
completion status was not returned before the failure. 

• The new data is partially written to the media so that some of the disk blocks 
involved in the I/O contain the data from the write operation in progress, 
and the remainder of the blocks contain the data that was present before the 
write operation. 

• The new data was never written to the disk blocks on the media. 

To guarantee that a write operation either finishes successfully or (in the event 
of failure) is redone or rolled back as if it were never started, use additional 
techniques to assure data correctness and recovery. For example, using database 
journaling and recovery techniques allows applications to automatically recover 
from failures such as the following: 

• Permanent loss of the path between a CPU data buffer containing the data 
being written and the disk being written to during a multiple-block I/O 
operation. Communication path loss can occur due to node or controller 
failure or a failure of node-to-node communications. 

• Failure of a CPU (such as a system failure, system halt, power failure, or 
system shutdown) during a multiple-block write operation. 

• Mistaken deletion of a file. 

• Corruption of file system pointers. 

• File corruption due to a software error or incomplete bucket write operation 
to an indexed file. 

• Cancellation of an in-progress multiple-block write operation. 

5.19 LIB$FIND_IMAGE_SYMBOL Routine — Problem Corrected 

V6.1 In OpenVMS AXP Version 1.5, the LIB$FIND_IMAGE_SYMBOL routine 

sometimes used an incorrect value as the base address of an image’s symbol 
vector, resulting in an access violation. 

This problem has been fixed for Version 6.1. The original Version 1.5 release 
note described the use of a logical name to invoke an uninstalled copy of the 
affected library. Care should be taken to delete any such logical created to deal 
with the original problem. Another Version 6.1 release note described a potential 
conflict with images installed with shareable linkage and attempted activation of 
uninstalled copies. 

5.20 LIBRARIAN Operation Failure 

VI .5 The OpenVMS AXP LIBRARIAN sometimes does not inform you of errors 

during compression, data reduction, or data expansion operations. This problem 
occurs if the account or process in which the LIBRARIAN is running has a low 
PGFLQUOTA process quota. Operation failure is not readily apparent because 
the $PUTMSG system service always returns a status of SS$_NORMAL, even 
when the system service fails. However, when a failure occurs, the LIBRARIAN 
returns a status other than success. 
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To work around this problem, run the compression, data reduction, or data 
expansion operation in an account with a PGFLQUOTA process quota greater 
than 23000. In addition, ensure that your command procedures check the return 
status from the LIBRARY command. 

5.21 Linker Utility 

The following sections apply to the OpenVMS AXP Linker utility (linker). 

5.21.1 Suggestion for Improving Application Code Performance 

VI.5 You can improve the performance of your application code by taking advantage 

of the granularity hint region (thereby improving utilization of the translation 
buffer). To do this, link the program with the /SECTION_BINDING switch and 
install the program with the /RESIDENT switch. For more information, see the 
OpenVMS Linker Utility Manual and the OpenVMS System Manager's Manual. 

5.21.2 Restrictions 

V1.0 The following restrictions apply to the linker: 

• The linker has been modified so that a new error message informs you at 
link time that global symbols from shareable images are being placed into 
byte- or word-sized fields by the linker. (Word- and byte-sized stores of global 
symbols do not generate fixup information. Fixup information is required 
when linking against shareable images.) When this situation occurs, an error 
message is printed, and image production is inhibited. 

The following example shows this new error message: 

%LINK-E-NOFIXSYM, unable to perform WORD fixup for symbol TPU$_0PTI0NS 

in psect $PLIT$ in module TEST_M0DULE file USER:[ACCOUNT]TEST.OLB;1 

To work around this restriction, move the symbolic value into the desired 
location at run time rather than at link time. For example, in MACRO, 
rather than performing .WORD TPU$_OPTIONS, use the instruction MOVW 
#TPU$_OPTIONS,desL 

• The OpenVMS AXP Version 1.0 linker cannot overlay program sections that 
are referenced by symbol definitions with shareable image program sections 
of the same name. Symbol definition records that contain the index of an 
overlaid program section are generated by the C compiler when the relaxed 
ref-def extern model is used (the default). Shareable image program sections 
are created when you link a shareable image and use the PSECT keyword in 
your SYMBOL_VECTOR option. 

If the linker detects this condition, it issues the following error: 

%LINK-E-SHRSYMFND, shareable image psect <name> was pointed to by a symbol definition 
%LINK-E-N0IMGFIL, image file not created 

The link continues, but no image is created. To work around this restriction, 
change the symbol vector keyword to DATA, or recompile your C program 
with the qualifier /EXTERN=COMMON. 
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5.22 Lock Manager Synchronization Changes 

V6.1 The synchronization for the OpenVMS lock manager has changed with this 

release of OpenVMS AXP. A new spin lock with a name of LCKMGR is now 
used to synchronize the OpenVMS lock manager for standalone OpenVMS AXP 
machines. AXP systems running as part of a VMScluster still synchronize with 
the SCS (IOLOCK8) spin lock. Use of the LCKMGR spin lock in a VMScluster 
system will correctly lock the SCS spin lock. 

This change has no impact for users of the system service interfaces of $ENQ[W], 
$DEQ, and $GETLKI[W]. 

If you have code that currently accesses OpenVMS internal lock manager data 
structures such as LKBs or RSBs, you will need to modify your software to 
correctly synchronize with the lock manager by using the LCKMGR spin lock. 
This change does not affect OpenVMS VAX software. 

5.23 LTDRIVER Restriction 

V6.1 LTDRIVER did not set the "extended DDT" bit; therefore, the POSIX function 

CANCEL SELECTIVE did not work with LTDRIVER. This has been fixed, but a 
restriction remains. 

Although this fix allows $QIO reads and writes to be selectively canceled, 
any $QIO done to the port driver (that is, with the IO$_TTY_PORT function 
modifier—like a LAT connect $QIO) cannot be canceled with CANCEL 
SELECTIVE. This problem will be addressed in a future OpenVMS release. 

5.24 MACRO-32 Compiler for OpenVMS AXP 

The following sections contain information pertaining to the MACRO-32 Compiler. 

5.24.1 MACRO-32 Compiler Now Native 

V6.1 The MACRO-32 Compiler executable image is now native rather than translated, 

which should result in noticeable performance improvements. 

5.24.2 New Function 

VI.5 When /FLAGGING=INSTRUCTIONS is enabled, absolute addresses detected by 

the compiler are flagged. This function is not documented in Migrating to an 
OpenVMS AXP System: Porting VAX MACRO Code. For example, MOVL RO, 

200 compiles correctly (updating memory location 200), but the desired absolute 
address may be different on an AXP computer. As a result, the informational 
message CHKABSADR is reported. The /NOFLAG=INSTRUCTIONS qualifier 
prevents these informational messages from being reported. 

5.24.3 When to Declare Entry Points 

V6.1 Any code label that is a possible target of a CALLS, CALLG, JSB, BSBW, or 

BSBB instruction must be declared as an entry point. In addition, any code label 
must be declared as an entry point using a .JSB_ENTRY or .JSB32_ENTRY 
directive if: 

• The label can be the target of a global (cross-module) JMP, BRB, or BRW 
instruction 

• The label can be the target of an indeterminate branch (such as BRB @(R10)), 
where the address of the label has been stored in RIO, even if the reference 
and the label are within the same module 
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5.24.4 

V1.5 


V6.1 


V6.1 


• The address of the label is stored in a register or memory location, even if it 
is never accessed by the current module 

The OpenVMS calling standard for Alpha AXP computers does not provide 
a way to access indeterminate code addresses directly. All such accesses are 
accomplished using a procedure descriptor to describe the routine and the code 
address. When a code label address is stored, the compiler does not know if 
that address will be referenced only by the current module, or whether it may 
be accessed by another MACRO module or another module written in another 
language. Whenever the MACRO—32 compiler stores a code address, it always 
stores the procedure descriptor for that address so that other code can access it 
correctly. For a procedure descriptor address to exist, the label must be declared 
as an entry point. 

Likewise, when a stored address is used as a destination, the compiler does 
not know where that address came from, so it always assumes that the stored 
address is the address of a procedure descriptor and uses that descriptor to pass 
control to the routine. 

Restrictions and Known Problem 

The following restrictions exist in this version: 

• The MACRO-32 Compiler does not support the creation of separate object 
files from source files separated by a comma (,). 

• Because packed-decimal instructions and floating-point instructions are 
implemented by means of macros, there is one restriction on the format of the 
arguments. In a macro invocation, an initial circumflex ( A ) is interpreted to 
mean that the parameter is a string and the character immediately following 
the circumflex is the string delimiter. Because of this, you cannot use 
arguments that begin with an operand type specification, such as A x20(SP). 
Note that immediate mode arguments, such as # A XFF, can use an operand 
type specification because the circumflex is not the initial character. 

• For procedures declared using the .JSB_ENTRY directive, the MACRO- 
32 Compiler automatically generates a null frame procedure descriptor, 
independent of debug or optimization qualifiers. The null frame procedure 
descriptor allows for debugging of problems with the linkage itself. 

Because no new context is set up by a null frame procedure, a side effect is 
that there is no guarantee of completely accurate debugger information about 
such procedures in response to SHOW CALLS and SHOW STACK commands. 
For example, the line number in the called null procedure (to which a JSB is 
done) may be reported as the line number in the calling procedure from which 
the JSB is issued. 

• A MACRO program that calls out to a routine and expects a floating-point 
return value in RO may require a “jacket” between the call and the called 
routines to move the returned value from floating-point register 0 to RO. 

The following problem exists in this version: 

INSV instructions do not generate code that correctly preserves granularity 
when granularity preservation is turned on. 

See Section 6.7 for information about corrections that apply to the Migrating to 
an OpenVMS AXP System: Porting VAX MACRO Code. 
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5.25 

V6.1 


5.26 

5.26.1 

V6.1 


5.26.2 

V6.1 

5.26.3 

V6.1 


5.26.4 

V6.1 

5.26.5 

V6.1 


Data Size Returned by Callable MAIL User Routines Corrected 

Programs that call the MAIL$USER_BEGIN and MAIL$USER_GET_ INFO user 
routines can request that these routines use a 16-bit word to store the length (in 
bytes) of returned information at an address that the calling program specifies in 
the output item list. 

Prior to OpenVMS AXP Version 6.1, these user routines were encoding the length 
of the returned information in a longword (32 bits) rather than a word (16 bits), 
thus overwriting space adjacent to the specified address. 

The problem has been corrected by ensuring that these routines encode the length 
of the returned information in a word. 

POLYCENTER Software Installation Utility Restrictions 

Notes in this section pertain to problems and restrictions with using the 
POLYCENTER Software Installation utility to create software kits. 

Alphanumeric Options Not Supported 

You cannot allow installers to specify alphanumeric configuration choices using 
the POLYCENTER Software Installation utility. The option statement allows 
only Boolean configuration choices. 

Digital expects to correct this problem in a future release. 

Alternate File Placement Not Supported 

You cannot specify an alternate location for some of your product files using the 
POLYCENTER Software Installation utility. 

Digital expects to correct this problem in a future release. 

Command Procedure Behavior 

The following product description file (PDF) statements use command procedures 
to perform the creation and deletion of managed objects: 

• account 

• network object 

• rights identifier 

In a future version, the POLYCENTER Software Installation utility may 
create and delete these managed objects directly without the use of command 
procedures. If this is the case, these statements will continue to function, but the 
command procedures may not be maintained or shipped with future versions of 
the utility. 

Conflict Error Reporting 

Some error messages indicating managed object conflicts do not identify the 
related products. 

Error Reporting 

When packaging a kit, you may receive many different errors (for example, wrong 
keywords or missing directives) in your product description file (PDF). In several 
cases, the utility error messages do not contain enough information to determine 
the problem with the PDF. 

Digital expects to correct this problem in a future release. 
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5.26.6 File Conflict Resolution Problem 

V6.1 If you specify a file statement without the generation option, the utility assigns 

the file generation zero (rather than not assigning a generation number as the 
documentation states). 

By default, the utility should not assign a generation number unless one is 
specified. Currently, a file with a generation option greater than zero will 
supersede an installed file of the same name without generating a message. The 
utility should detect this as a conflict and display a message. 

5.26.7 File Statement Generation Limit 

V6.1 The generation option on the file statement allows generation numbers only 

as high as 4230196224. If you specify a larger number, the utility truncates it 
without warning. 

5.26.8 Future Statement Compatibility 

V6.1 The product description language (PDL) of the POLYCENTER Software 

Installation utility has no provision for forward compatibility (the ability for 
future statements to work with this version of the utility). This means that 
kits that use a statement or syntax not supported in this version will not work 
correctly. 

5.26.9 Internationalization Support Restrictions 

V6.1 Internationalization support for using command procedures with execute 

statements is not available with this version of the utility. 

Digital expects to correct this problem in a future release. 

Multiple Execute Remove Statements Problem 

There is a problem with the execute remove statement where only the first one 
executes during a remove operation. However, all of the execute install statements 
execute during an install operation. 

Digital expects to correct this problem in a future release. 

5.26.11 Multiple Operating Scopes Not Supported 

V6.1 Multiple operating scopes are not supported and may not work correctly in 

certain circumstances. 

Digital expects to correct this problem in a future release. 

Network Object Statement — Problem 

The command procedure that creates network objects for the network object 
statement asks the product developer for the network object number. This is 
information that the installer, not the product developer, has access to. Also, the 
utility does not provide a way for the installer to enter this information. 

5.26.13 Package Operation Errors 

V6.1 If you receive error messages while creating a sequential kit using the PACKAGE 

command, the resulting kit may be unusable. Attempting to install such a kit 
will result in the following error message: 

%PCSI-E-INVDOCMTL, document has invalid product material ordering 
To avoid such installation problems, repackage the kit before shipping it. 


5.26.12 

V6.1 


5.26.10 

V6.1 
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5.26.14 Removing Accounts and Rights Identifiers — Restrictions 

V6.1 Removing a product with the POLYCENTER Software Installation utility results 

in the removal of accounts specified by account statements. The utility should not 
do this in all cases because the file SYSUAF.DAT may be clusterwide or local to a 
single system disk or groups of system disks. 

If you install software on a particular system disk, any account statements create 
the necessary accounts. If you install the software on a second system disk that 
shares the same SYSUAF.DAT file, the account already exists and does not need 
to be created. 

When you remove a product, the utility always removes the account, regardless of 
whether the SYSUAF.DAT file is shared by another system disk. 

The same problem exists with the rights identifier statement and the file 
RIGHTSLIST.DAT. 

Digital expects to correct these problems in a future release. 

5.26.15 Source and Destination Constraints for Package Operation 

V6.1 A typical task when creating software kits is to create a sequential kit by 

performing a package operation. If you use the same directory for the source and 
destination for your package operation, you can create problems for future install 
operations that use the directory as a source. 

If both a sequential kit and a file with the file type .PCSI$DESCRIPTION are 
in the same directory, an install operation that points to that source area always 
opens the file with the file type .PCSI$DESCRIPTION. This can cause errors 
locating product material if it is not in the same place. There is no way to specify 
the sequential kit for the installation. 

To avoid this problem, use separate directories for the source and destination of 
your package operations. 

5.26.16 “Uses” Clause of Two Execute Statements — Restriction 

V6.1 You cannot specify the same file in the “uses” clause of two separate execute 

statements in the same PDF, for example: 

product DEC AXPVMS MYSTUFF full; 

execute install "@doit thisway" uses [000000]doit.com; 
execute install "@doit thatway" uses [000000jdoit.com; 

end product; 

The file is deleted before the second use. 

Digital expects to correct this problem in a future release. 

5.27 Programming Consideration for Manipulation of Absolute 
Queues 

V1.0 Some programming languages, such as Bliss, manipulate absolute queues using 

queuing instructions hidden within a macro definition found in STARLET. These 
macro operations are not atomic. For example, the BLISS REMQUE macro can 
be interrupted between the instruction that loads the entry to be removed and 
the instruction that removes the entry from the queue, as shown: 
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LDL R16, n(Rn) ; pointer to element in queue 

REMQUEL ; remove element from queue 

This is most notable when a specific absolute queue manipulation occurs at a 
level other than AST but gets interrupted by an AST routine also manipulating 
the same absolute queue. The appropriate instruction to use in this case is 
REMQUEL/D, as shown in the following example: 

MOV Rn, R16 ; address of pointer to element in queue 

REMQUEL/D ; remove element from queue 

This instruction performs the same operation as REMQUEL but is addressed by 
the longword addressed by R16. This guarantees behavior like that found on VAX 
systems. 

See the Alpha Architecture Reference Manual for further details about deferred 
queue instructions. 

5.28 RMS Error Changes 

V6.1 If you attempted to retrieve, insert, or update a record prior to OpenVMS AXP 

Version 6.1, the following errors would be returned if any buffer was too small for 
the record: 


Operation Message 

$GET (or DCL READ) %RMS-W-RTB, nnn byte record is too large for users buffer 

$PUT or $UPDATE (or %RMS-F-RSZ, invalid record size 

DCL WRITE or WRITE 

/UPDATE) 


As of OpenVMS AXP Version 6.1, these errors are returned only if the buffer that 
is too small is one of the user record buffers (pointed to by either RAB$L_UBF 
or RAB$L_RBF) allocated in the user application. If the file is a remote file and 
the buffer that is too small is one for which the size is determined by the network 
block count (NBC), then the new RMS-E-NETBTS (network buffer too small) 
error status is returned. User action assistance for responding to this error is 
provided in the Help message database. 

5.29 Run-Time Libraries 

The following sections apply to run-time libraries. 

5.29.1 Run-Time Libraries Not Included 

VI.5 The run-time libraries listed in Table 5-3 are not included in this version of 

OpenVMS AXP. 


Table 5-3 Run-Time Libraries Not Included 


DBGSSISHR 

DNS$RTL 

DNS$SHARE 

VBLAS1RTL 


DEBUG item, replaced by SYS$SSISHR on OpenVMS AXP 
No DNS in OpenVMS AXP 
No DNS in OpenVMS AXP 
No support for VAX vector programs 


(continued on next page) 
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Table 5-3 (Cont.) Run-Time Libraries Not Included 

VMTHRTL No support for VAX vector programs 


Most run-time libraries that were available in OpenVMS VAX Version 5.5-2 are 
available in this version of OpenVMS AXP. The OpenVMS VAX Version 5.5-2 
libraries that are not available are either not being ported to OpenVMS AXP or 
are planned for a later release of OpenVMS AXP. 

For example, the vector math libraries VBLAS1RTL and VMTHRTL are not 
available in OpenVMS AXP because there is no support on OpenVMS AXP for 
programs that use the VAX vector instructions. 

5.29.2 Compatibility Between the VAX and AXP Mathematics Libraries 

V1.0 Mathematical applications using the standard OpenVMS call interface to the 

OpenVMS Run-Time Mathematics (MTH$) Library need not change their calls to 
MTH$ routines when migrating to an AXP system. Jacket routines map MTH$ 
routines to their math$ counterparts in the Digital Portable Mathematics Library 
(DPML) for OpenVMS AXP. However, there is no support in the DPML for calls 
made to JSB entry points and vector routines. Note that DPML routines are 
different from those in the OpenVMS Run-Time Mathematics (MTH$) Library. 
You should expect to see small differences in the precision of the mathematical 
results. 

If one of your goals is to maintain compatibility with future libraries and to create 
portable mathematical applications, Digital recommends that you use the DPML 
routines available through the high-level language of your choice (for example, 
DEC Fortran and DEC C) rather than using the call interface. Significantly 
higher performance and accuracy are also available to you with DPML routines. 

See the Digital Portable Mathematics Library manual for more information about 
DPML. 

5.30 Security Changes 

V6.1 OpenVMS Version 6.1 offers significant enhancements to system security and 

some of these changes can affect your everyday operations. For this reason, take 
special note of the changes identified in Section 3.24.1. 

5.30.1 Site-Specific Hash Algorithm Change 

V6.1 Two changes were made the site-specific password hash algorithm example code 

in SYS$EXAMPLES:HASH_PASSWORD.MAR. Sites using this file as a basis 
for a site-specific password hash algorithm must recompile and relink their 
SYS$HASH_PASSWORD executive loadable images based on the new template. 
However, unless modifications were made to the Digital supplied preamble code in 
the example, you need not be concerned with the following functional changes. As 
before, site-specific algorithm dispatching generally replaces a 'NOP" instruction 
in the template. 

First, the value of UAF$C_PREFERRED_ALGORITHM has been changed from 
3 to 127. The new value will remain constant from now on. Existing binary 
images that reference the preferred algorithm using the old value will continue to 
function, but will need to be recompiled and relinked if the preferred algorithm 
were ever to change. With this change, such images will have to recompile only 
once. 
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Second, user-mode probing of the formal parameters is now conditionally 
assembled based on the PROTECT conditional assembly prefix. If the service 
is being assembled as an exec-mode service, PROBEs are still used. Otherwise, 
the system condition handler EXE$SIGTORET is used to turn user-mode signals 
into their corresponding return status values. This change corrects a problem 
seen when using $HASH_PASSWORD with static watchpoints in the OpenVMS 
Debugger. 

5.31 STARLET Data Structures and Definitions for C Programmers 

VI.0 OpenVMS AXP Version 1.0 includes a new file, SYS$STARLET_C.TLB, that 

contains all the .H files that provide STARLET functionality equivalent 
to STARLETSD.TLB. The file SYS$STARLET_C.TLB, together with 
DECC$RTLDEF.TLB now shipping with the DEC C Compiler, replaces 
VAXCDEF.TLB that previously shipped with the VAX C Compiler. 
DECC$RTLDEF.TLB contains all the .H files that support the compiler and 
RTL, such as STDIO.H. 

The following differences may require source changes: 

• RMS structures 

Previously, the RMS structures FAB, NAM, RAB, XABALL, and so forth, were 
defined in the appropriate .H files as “struct RAB {...”, for example. The .H 
files to be supplied in OpenVMS AXP Version 1.0 will define them as “struct 
rabdef {...”. To compensate for this difference, lines of the form “#define RAB 
rabdef” have been added. However, there is one situation where a source 
change is required because of this change. If you have a private structure 
that contains a pointer to one of these structures and your private structure 
is defined (but not used) before the RMS structure has been defined, you will 
receive compile-time errors similar to the following: 

%CC-E-PASN0TMEM, In this statement, "rab$b_rac" is not a member of "rab". 

This error can be avoided by reordering your source file so that the RMS 
structure is defined before the private structure. Typically, this involves 
moving around “#include” statements. 

• LIB (privileged interface) structures 

Historically, three structures from LIB (NFBDEF.H, FATDEF.H, and 
FCHDEF.H) have been made available as .H files. These files were 
shipped as .H files in OpenVMS AXP Version 1.0 and 1.5 (not in the new 
SYS$STARLET_C.TLB). In OpenVMS AXP Version 6.1, the file SYS$LIB_ 
C.TLB, containing all LIB structures and definitions, has been added. These 
three .H files are now part of that .TLB and are no longer shipped separately. 
Source changes may be required, as no attempt has been made to preserve 
any existing anomalies in these files. The structures and definitions from LIB 
are for privileged interfaces only and are therefore subject to change. 

• Use of “variant_struct” and “variant_union” 

In the new .H files, “variant_struct” and “variant_union” are always used, 
whereas previously some structures used “struct” and “union”. Therefore, 
the intermediate structure names cannot be specified when referencing fields 
within data structures. 

For example, the following statement: 

AlignFaultItem.PC[0] = DataPtr->afr$r_pc_data_overlay.afr$q_fau!t_pc[0]; 
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becomes: 

AlignFaultItem.PC[0] = DataPtr->afr$q_fault_pc[0]; 

• Member alignment 

Each of the .H files in SYS$STARLET_C.TLB saves and restores the state of 
“#pragma member_alignment”. 

• Conventions 

The .H files in SYS$STARLET_C.TLB adhere to some conventions that 
were only partly followed in VAXCDEF.TLB. All constants (#defines) have 
uppercase names. All identifiers (routines, structure members, and so forth) 
have lowercase names. Where there is a difference from VAXCDEF.TLB, the 
old symbol name is also included for compatibility, but users are encouraged 
to follow the new conventions. 

• Use of Librarian utility to access the .H files 

During installation of OpenVMS AXP Version 1.0, the contents of 
SYS$STARLET_C.TLB are not extracted into the separate .H files. The 
DEC C Compiler accesses these files from within SYS$STARLET_C.TLB, 
regardless of the format of the #include statement. If you want to inspect 
an individual .H file, you can use the Librarian utility, as in the following 
example: 

$ LIBRARY /EXTRACT=AFRDEF /0UTPUT=AFRDEF.H SYS$LIBRARY:SYS$STARLET_C.TLB 

• Additional .H files included in SYS$STARLET_C.TLB 

In addition to the .H files derived from STARLET sources, SYS$STARLET_ 
C.TLB includes .H files that provide support for DECthreads, such as CMA.H. 


5.32 System Dump Analyzer Utility (SDA) Notes 

The following sections describe an enhancement and some problems that affected 
the System Dump Analyzer utility (SDA) that have been fixed. 


5.32.1 SHOW MACHINE.CHECK Command Available 

VI.0 The SDA SHOW MACHINE_CHECK display works for the DEC 4000 AXP and 

DEC 7000 Model 600 AXP platforms only. Note that the SHOW MACHINE_ 
CHECK command displays available information even if the cause of the system 
failure was something other than a machine check. The data is guaranteed to be 
accurate only if the bugcheck code for the failure is a machine check. 

The following display applies to a DEC 7000 Model 600 AXP machine check: 

Processor specific information: 


Exception address: 

Pal base address: 

HW Interrupt Request: 
MM_CSR 

D-cache address: 

BIU status: 

BIU control: 
Single-bit syndrome: 
A-box control: 


00000000 00030122 
00000000 00008000 
00000000 00000342 
00000000 00005120 
00000007 FFFFFFFF 
00000000 00000041 
00000008 50006447 
00000000 00000000 
00000000 0000040E 


Exception Summary: 
Exception Mask: 

HW Interrupt Ena: 
ICCSR: 

D-cache status: 

BIU address [7.. 0 ]: 
Fill Address: 
Processor mchck VA: 
B-cache TAG: 


00000000 00000000 
00000000 00000000 
00000001 FFFFDCE0 
00000003 F81F0000 
00000000 000002E0 
00000003 F8400000 
00000000 00006120 
00000000 00006190 
0000609A 30482000 
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5.32.2 

V6.1 


System specific information: 


Garbage bus info: 
LCNR: 

LBER: 

Bus error cmd: 

LEP mode: 


00300009 000000B0 
00000001 
00001081 
00000020 00420000 
00010010 


Device type: 

Memory error: 

Bus error synd 0,1: 
Bus error synd 2,3: 
LEP lock address: 


00008001 
00000000 
0000000C 0000000C 

oooooooc oooooooc 

00091B86 


Problems Corrected 

The following problems that existed in Version 1.5 of SDA have been corrected: 

• When you enable full console messages (by setting the DUMPSTYLE system 
parameter to 0 or 1) and an error halt restart bugcheck occurs (such as kernel 
stack not valid), the bugcheck code causes an access violation while trying to 
print out stack information on the console. 

As a result, a recursive bugcheck message is printed on the console. However, 
SDA continues to write the dump file based on the original crash. The dump 
file is created as if the recursive bugcheck never happenned. 

Digital expects to fix this problem in a future release. 

• The REFCNT field in the SHOW PAGE_TABLE and SHOW 
PROCESS/PROCESS_SECTION displays is too narrow and prevents large 
values from being printed. The field displays asterisks (*) to indicate this 
problem. In a future release, the REFCNT field will be widened. 

• The FLAGS field in the SHOW PROCESS/PHD display shows only a word 
of data even though a longword of data may be present. This field will be 
increased for a future release. 

• The ADDRESS column for the SHOW PROCESS/PROCESS_SECTION 
display may contain the wrong value for PI space sections. To determine if 
the value is incorrect, compare the value in the ADDRESS column with the 
“First free PO address” field of the SHOW PROCESS/PHD display. If the 
value in the ADDRESS column is greater, it is a PI space section. 

To calculate the correct address, enter the following command, where n 
represents the address displayed in the ADDRESS field: 

SDA> EVAL (((n/2000)-((@sgn$gl_ptpagcnt)@a))*2000) & #80000000 

• The SHOW POOL/NONPAGED command does not work if nonpaged pool is 
exhausted (that is, when no memory is available). Instead, SDA immediately 
returns the following error: 

%SDA-E-NOREAD, unable to access location 00000000 
There are no workarounds. 

• EXAMINE 0:FFFFFFFF does not work. You cannot examine a range that 
crosses from PO to PI space or from PI to system space. You must examine 
the ranges separately, as in the following example: 

SDA> EXAMINE 0:3FFFFFFF 
SDA> EXAMINE 40000000:7FFFFFFF 
SDA> EXAMINE 80000000:FFFFFFFF 

• If an access violation occurs during a bugcheck, system space may not 
be saved. When this happens, SDA cannot analyze the dump. However, 
instead of returning meaningful information, SDA returns the following error 
message: 


5-40 




Programming Release Notes 
5.32 System Dump Analyzer Utility (SDA) Notes 


%LIB-F-BADBLOSIZ, bad block size 

5.33 System Services Notes 

The following sections describe changes and a restriction that apply to system 
services in OpenVMS AXP. 

5,33.1 Low Four Bits of Chan Argument Are Checked — Change 

V1.0 The chan argument is used in a number of system services to pass a channel 

number. Historically, the operating system has always regarded the chan 
argument as a 16-bit unsigned number but has never used the low four bits of 
the argument. Thus, it is possible that some user programs might use the low 
four bits of the argument as temporary storage unrelated to the channel number. 

Now, the low four bits of the chan argument are checked. If any bit is nonzero, a 
status code of SS$_IVCHAN is returned to the caller of the service. Modify your 
source code to properly store user information in a location other than the chan 
argument. 

Condition Code SS$_PAGRDERR Changed 

The signal argument of the SS$_PAGRDERR condition has been changed. Prior 
to OpenVMS AXP Version 6.1, the first signal argument was the mask of the 
“transition not valid” reason. In OpenVMS AXP Version 6.1, this argument has 
been changed to provide the actual I/O failure status that caused the page read 
error. 


5.33.2 

V6.1 


Condition Name 

Explanation 


SS$_PAGRDERR 

Type: 

Fault 


Description: 

Read error occurred during an attempt to 
read a faulted page from disk. 


Arguments: 

1. I/O failure status. 

2. Virtual address of referenced page. 


5.33.3 $FORMAT_AUDIT Width Argument Does Not Work Consistently — 
Restriction 

VI.0 The width argument to the $FORMAT_AUDIT system service does not work 

consistently. In most cases, if you specify both the width argument and the full 
format style (NSA$C_FORMAT_STYLE_FULL), $FORMAT_AUDIT ignores the 
width argument. The minimum width is 80 columns; lower values do not limit 
the width to less than 80. If you specify a width greater than 80 columns, most 
lines are not joined to use the full width. 

In general, avoid using the width argument. 

5.33.4 $GETJPI System Service — New JPI$_DFMBC Item Code 

VI.5 JPI$_DFMBC is a new item code for the $GETJPI system service. When you 

specify JPI$_DFMBC, $GETJPI returns the default multibuffer count for a 
process as a longword integer value. 
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5.33.5 $SUSPND System Service in a Cluster Environment — Incorrect 
Behavior 

VI.5 When the $SUSPND system service is called and the target process is on a 

different cluster node than that of the process calling the $SUSPND service, the 
kernel mode suspend flag (bit 0) is ignored. As a result, any suspend is treated as 
a supervisor-mode suspend. 

Digital expects to fix this problem in a future version of OpenVMS AXP. 

5.34 Traceback Handler Support 

V1.0 Traceback handler support is present in OpenVMS AXP Version 1.0. The 

following items describe the available support: 

• Symbolic traceback is supported, including traceback for images installed 
/RESIDENT. 

The symbolic information that is reported includes the image name in which 
the invocation PC lies, the module name, the routine name, and the line 
number. Two PC values are also provided: 

— Relative (to the routine base address) 

— Absolute 

If the traceback handler must resort to nonsymbolic information (because 
there is no symbolic information in the image), then the relative PC is relative 
to the image base address. 

• The traceback handler supports the (nonsymbolic) display of translated VAX 
call frames. 

• Exception frame reporting has been implemented. 

5.35 Translated Image Support 

V6.1 At the beginning of the OpenVMS AXP program, translation support was 

provided to remove impediments for users moving to Alpha AXP due to: 

• Lack of full language support initially 

• Unavailability of source code for recompilation 

• Difficulty of recompiling code that depended heavily on certain features of the 
VAX architecture 

For languages whose VAX versions are undergoing active development, native 
Alpha AXP versions are now available. The Translated Image Environment is 
being maintained to support those language features that were available as of the 
release of OpenVMS VAX Version 5.5-2. 

Similarly, translation is supported for images whose use of system services and 
run-time library entry points is restricted to those that existed on OpenVMS VAX 
Version 5.5-2. 

In cases where more recent VAX layered products have been installed, it may be 
necessary to take minor additional steps if application needs require rebuilding 
an image suitable for translation. For instance, with DECwindows Motif Version 
1.2 for OpenVMS VAX, images must be built with the OSF Motif Version 1.1.3 
library or the DECwindows XUI library rather than the OSF Motif Version 1.2.2 
library in order to be suitable for translation. 
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Similarly, for those using recent versions of DEC Fortran for VAX, an additional 
qualifier is required in order to compile FORTRAN programs so that they are 
suitable for translation. 

For further information, see the release notes for particular VAX products. 

As a safety measure for situations where future rebuilding and retranslation of 
OpenVMS VAX images is likely, it may be preferable to save copies of the relevant 
OpenVMS VAX Version 5.5-2 shareable images in a separate VAX directory and 
link new versions of VAX applications against those images. Using that technique 
the resulting images will be compatible with newer OpenVMS VAX shareable 
images (picking up any OpenVMS enhancements of existing features) and will 
also be properly built for translation to OpenVMS AXP (by not requiring newer 
versions of shareable images). 

5.36 Translated Image Environment (TIE) Notes 

VI.5 Image translation is one means of migrating all or part of a VAX application 

to OpenVMS AXP. The DECmigrate for OpenVMS AXP VAX Environment 
Software Translator utility (VEST) creates a translated image by converting a 
VAX executable or shareable image into a functionally equivalent AXP image. 
VEST is a component of the optional layered product DECmigrate for OpenVMS 
AXP. 

When a translated image runs on OpenVMS AXP, the Translated Image 
Environment (TIE) provides the VAX environment required for the image to 
execute properly. The TIE consists of the shareable images TIE$SHARE and 
TIE$EMULAT_TV, which performs VAX complex instructions. For information on 
the role of image translation in a migration strategy, see the manuals Migrating 
to an OpenVMS AXP System: Planning for Migration and DECmigrate for 
OpenVMS AXP Systems Translating Images. 

OpenVMS AXP Version 1.5 supports translation of programs from OpenVMS VAX 
Version 4.0 through Version 5.4-3. Although VEST translates Version 5.5 images, 
OpenVMS AXP Version 1.5 might not provide the necessary run-time support 
because the translated libraries are based on Version 5.4-3. In this case, the 
translated OpenVMS VAX Version 5.5 image may get an ident mismatch at run 
time. 

The following sections discuss these topics: 

• Interoperability between native and translated images 

• Running translated images 

• TIE statistics and feedback 

• TIE restrictions 

5.36.1 Interoperability 

V1.0 The TIE works together with other components of OpenVMS AXP to enable 

native and translated images to interoperate, that is, to call one another. If you 
are developing applications or run-time libraries that rely on interoperability, you 
need to follow certain procedures when compiling, linking, or translating. See 
the first restriction described in Section 5.36.4. Table 5—4 provides pointers to 
documentation that describes the procedures. 
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5.36.2 

vi.o 


5.36.3 

vi.o 


Table 5-4 Interoperability Documentation 


Goal 

Reference 

Ensuring interoperability between native 
and translated images 

Migrating to an OpenVMS AXP System: 
Recompiling and Relinking Applications 


DECmigrate for OpenVMS AXP Systems 
Translating Images 

Coordinating native and translated 
run-time libraries 

DECmigrate for OpenVMS AXP Systems 
Translating Images 


Running Translated Images 

Use the DCL RUN command to run a translated image. For example: 

$ RUN FOO_TV.EXE 

Note that the translated image will not run correctly unless OpenVMS AXP 
includes the appropriate translated shareable images and run-time libraries. 
When you translate an image, VEST requires the image information files (IIFs— 
file type .IIF) corresponding to whichever images and libraries that the input 
image refers to. These .IIF files enable VEST to create a translated image that 
correctly refers to the translated versions of the shareable images and libraries. 
An image information file used at image translation must exactly correspond to 
the version of the translated shareable image or run-time library available on 
OpenVMS AXP. 

OpenVMS AXP includes a set of translated run-time libraries and a matching set 
of image information files, which are listed in Section 5.37. Check these lists to 
determine if they include the libraries or shareable images referred to by images 
you want to translate and run. If OpenVMS AXP does not include the required 
shared images or libraries, refer to the manual DECmigrate for OpenVMS AXP 
Systems Translating Images. This manual describes how to create and use image 
information files. 

Defining Logical Names for Libraries 

When a translated library has been replaced by a native version of the library, 
you need to define accordingly any logical names that point to it—that is, you 
need to redefine image_TV to image. 

TIE Statistics and Feedback 

In addition to the TIE’s run-time support function, TIE statistics and feedback 
can help to improve translated image performance: 

• The TIE can display statistics about the run-time execution of translated 
images. These statistics describe the image’s use of TIE resources and the 
interactions between images. 

• The TIE can record information about VAX entry points discovered while 
interpreting VAX code. When you retranslate the image, VEST uses the 
information to find and translate more VAX code. 

The manual DECmigrate for OpenVMS AXP Systems Translating Images 
describes these features in detail and explains how to define the logical names 
that enable and disable their use. 
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5.36.4 TIE Restrictions 

VI.5 The following restrictions apply to the TIE: 

Interoperability Restrictions 

• A native routine that either calls or is called by a translated image must 
be compiled with the /TIE qualifier and linked with the /NONATIVE_ONLY 
qualifier. Checking for interoperability between native and translated images 
occurs at run time. If the /TIE and /NONATIVE_ONLY qualifiers were not 
used to compile and link the native routine, an error will occur at run time 
when the the native routine and a translated image attempt to interoperate. 
If such an error occurs, recompile and relink the native routine appropriately. 

This restriction is permanent. 

• An access violation can occur at run time if a native routine that was not 
compiled with the /TIE qualifier makes an indirect call to a translated 
routine. The indirect call is made through a variable that contains the 
translated routine’s address. When this happens, there is no autojacketing 
code in place to assist the native-to-translated call. The native code attempts 
to use the routine address as a native procedure descriptor. The code address 
of a native procedure is at offset PDSC$L_ENTRY, whose value is 8, from the 
base of the procedure descriptor. Because the translated routine address is 
treated as a procedure descriptor, the value at offset 8 from that address is 
used as the code to call. This usually results in an access violation. 

If you are encountering this problem, use a debugger to check the following: 

• Check that R27 points into a translated image. 

• Check that bits <31:2> of 8(R27) equal bits <31:2> of the access violation 
address. (All bits are not used because Alpha AXP instructions are 
longword aligned.) 

• Check that R26 points into a native image. 

• Check that -4(R26) is a JSR R26,(26) instruction. 

If all these checks prove to be true, recompile the native routine with the /TIE 
qualifier to enable autojacketing at run time. 

Condition and Exception Handler Restrictions 

• There is a restriction on the type of condition handler that can be established 
for both native and translated images. A native routine cannot establish a 
translated condition handler, nor can a translated routine establish a native 
condition handler. If a native or translated image violates this restriction, the 
run-time results are unpredictable. 

This restriction is permanent. 

• Translated images with exception handlers that depend on receiving the 
correct program status longword (PSL) might not function properly. When 
exceptions are reported, the AXP program status (PS) is reported in the signal 
array instead because there is no VAX PSL. 

This restriction is permanent. 

• Translated images with exception handlers that depend on modifying the 
PSL in the signal array do not function properly. The modified PSL is not 
propagated back to the faulting code. 

This restriction is permanent. 
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Floating-Point Restrictions 

• In some cases, floating-point instructions operating on the same data generate 
a trap on an AXP system but not on a VAX system. Specifically, VAX floating¬ 
point instructions on OpenVMS AXP generate traps for the “dirty” zeros) that 
VAX hardware can handle correctly. “Dirty zeros” are floating-point values 
that are alternate encodings for zero. To retain compatibility with translated 
code that performs operations using dirty zeros, the TIE includes a condition 
handler that corrects the dirty zeros and retries the floating-point operation. 
However, the handler succeeds only if the qualifier /PRESERVE=FLOAT_ 
EXCEPTIONS was used when the image was translated. 

Images that were not translated with /PRESERVE=FLOAT_EXCEPTIONS 
and that perform an operation on a dirty zero incur an HPARITH exception 
with a summary status that has bit 1 set. If your translated application 
incurs one of these exceptions, retranslate with /PRESERVE=FLOAT_ 
EXCEPTIONS. VAX dirty zeros commonly result from not initializing floating 
data to 0. In this case, changes to source code may be necessary to port to 
OpenVMS AXP an application that uses dirty zeros. 

This restriction is permanent. 

• AXP D53 floating point (D_floating point as a 53-bit fraction instead of a 
56-bit fraction) is VAX D_floating converted to G_floating representation. 

This conversion leads to the following problem. Consider the VAX instruction 
sequence: 

MOVD (SP),R2 
MOVD R2,-(SP) 

VEST translates these VAX instructions into AXP code like the following: 


LDD F2,0(R14) 

CVTDG F2,F2 
CVTGD F2,F17 
STD F17,-8(R14) 


! Pickup D float 

! Convert to Canonical G Form with rounding 
! Convert back to D Form for storing 
! Store the result 


At run time, the VEST-generated code uses rounding to obtain the most 
accurate G_floating value when converting the D56 floating point to G 
canonical form. In some cases, the conversion to G canonical form may round 
up the D_floating value to create an exponent that cannot be represented in 
D_floating. When this happens, the CVTGD operation incurs an HPARITH 
trap with floating overflow as the summary reason. 

If a translated image incurs this problem at run time, it needs to be 
retranslated with the VEST qualifier /FLOAT=D56_FLOAT to execute 
properly. 

This restriction is permanent. 


Translated VAX C Program Restrictions 

• If a program uses the VAX C RTL routine brk() to release dynamic memory 
(that is, a break address lower than the current break address is requested), 
the next attempt by TIE to use a complex instruction routine may result 
in a fatal memory access violation. This may happen because the complex 
instruction routines are in a separate image, TIE$EMULAT_TV.EXE, which 
is dynamically activated via LIB$FIND_IMAGE_SYMBOL on the first use 
of one of the routines. Depending on when this occurs and the address 
passed to the brk() call that releases memory, the memory into which 
TIE$EMULAT_TV.EXE is loaded may also be released. 
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To avoid this problem, never use brk() to release memory, or be sure to 
execute a complex VAX instruction before getting the break address that is 
later used to release memory. Using brk() to allocate memory is fine. 

This restriction is permanent. 

• A translated VAX C program that uses vfork() and any executive function 
may hang at run time. If the child process of the VAX C program aborts 
erroneously, it may hang waiting for a mailbox I/O to be completed. One 
workaround is to prevent the child process from aborting. 

This restriction is permanent. 

5.36.5 Translated Image Environment Does Not Support Version 6.0 Features 

V6.1 System services and run-time library entry points newly added for OpenVMS 

VAX Version 6.0 are not yet supported with OpenVMS AXP Version 6.1. This 
means that VAX programs that use the new security services such as $CHECK_ 
PRIVILEGE cannot be translated with VEST (also called DECmigrate) for use on 
OpenVMS AXP Version T6.1. 

5.37 Translated Images and Related Files 

V6.1 This section lists the translated images, image information files, and other related 

files that are provided with OpenVMS AXP. 

OpenVMS AXP contains no translated message images. All message images have 
been made native. 

OpenVMS AXP contains the following translated images in SYS$LIBRARY: 

BASRTL2_D53_TV.EXE 

BASRTL2_D56_TV.EXE 

BASRTL_D56_TV.EXE 

BLAS1RTL_D53_TV.EXE 

BLAS1RTL_D56_TV.EXE 

COBRTL_D56_TV.EXE 

DBLRTL_D56_TV.EXE 

FORRTL2_TV.EXE 

FORRTL_D56_TV.EXE 

LIBRTL2_D56_TV.EXE 

LIBRTL_D56_TV.EXE 

MTHRTL_D53_TV.EXE 

MTHRTL_D56_TV.EXE 

PASRTL_D56_TV.EXE 

PLIRTL_D56_TV.EXE 

RPGRTL_TV.EXE 

SCNRTL_TV.EXE 

TECOSHR_TV.EXE 

TIE$EMULAT_TV.EXE 

UVMTHRTL_D53_TV.EXE 

UVMTHRTL_D56_TV.EXE 

VAXCRTLG_D56_TV.EXE 

VAXCRTL_D56_TV.EXE 

VMSRTL_TV.EXE 
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Open VMS AXP provides the following translated images in SYS$SYSTEM: 

DBLMSGMGR_TV.EXE 

EDF_TV.EXE 

MONITOR_TV.EXE 

TEC032_TV.EXE 

OpenVMS AXP contains the following translated images in IMAGELIB: 

BASRTL2_D53_TV.EXE 

BASRTL_D56_TV.EXE 

BLAS 1RTL_D53_TV.EXE 

COBRTL_D56_TV.EXE 

DBLRTL_D56_TV.EXE 

FORRTL2_TV.EXE 

FORRTL_D56_TV.EXE 

LIBRTL_D56_TV.EXE 

PLIRTL_D56_TV.EXE 

RPGRTL_TV.EXE 

SCNRTL_TV.EXE 

Note that most of the translated RTLs are provided in D56 format rather 

than D53 format; some are provided in both formats. Where both formats are 

provided, the default format is D53. See Section 5.38 for more information about 

the translated run-time libraries. 

OpenVMS AXP contains the following image information files in SYS$LIBRARY: 

ACLEDTSHR. IIF 

BASRTL2.IIF 

BASRTL.IIF 

BLAS 1RTL. IIF 

COBRTL.IIF 

CONVSHR.IIF 

CRFSHR.IIF 

DBLRTL.IIF 

DCXSHR.IIF 

DISMNTSHR.IIF 

DTKSHR.IIF 

EDTSHR.IIF 

ENCRYPSHR.IIF 

EPC$SHR.IIF 

FDLSHR.IIF 

FORRTL.IIF 

FORRTL2.IIF 

INIT$SHR.IIF 

LBRSHR.IIF 

LIBRTL.IIF 

LIBRTL2.IIF 

MAILSHR.IIF 

MOUNTSHR. IIF 

MTHRTL.IIF 

NCSSHR.IIF 

P1_SPACE.IIF 

PASRTL.IIF 

PLIRTL.IIF 

PPLRTL.IIF 
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PTD$SERVICES_SHR.IIF 

RPGRTL.IIF 

SO_SPACE.IIF 

SCNRTL.IIF 

SCRSHR.IIF 

SECURESHR.IIF 

SMBSRVSHR.IIF 

SMGSHR.IIF 

SORTSHR.IIF 

SPISHR.IIF 

TECOSHR.IIF 

TPUSHR.IIF 

UVMTHRTL.IIF 

VAXCRTL.IIF 

VAXCRTLG.IIF 

VMSRTL.IIF 

The following system logical names are defined in order to facilitate the 

translated environment: 

ACLEDTSHR_TV = ACLEDTSHR 
CDDSHR_TV = CDDSHR 
CONV SHR_TV = CONVSHR 
CRFSHR_TV = CRFSHR 
DCXSHR_TV = DCXSHR 
DISMNTSHR_TV = DISMNTSHR 
DTKSHR_TV = DTKSHR 
EN CRYPSHR_TV = ENCRYPSHR 
EPC$SHR_TV = EPC_SHR 
FDLSHR_TV = FDLSHR 
INIT$SHR_TV = INIT$SHR 
LBRSHR_TV = LBRSHR 
MAILSHR_TV = MAILSHR 
MOUNTSHR_TV = MOUNTSHR 
NCSSHR_TV = NCSSHR 
PPLRTL_TV = PPLRTL 

PTD$SERVICES_SHR_TV = PTD$SERVICES_SHR 

SCRSHR_TV = SCRSHR 

SECURESHR_TV = SECURESHR_JACKET 

SMBSRVSHR_TV = SMBSRVSHR 

SMGSHR_TV = SMGSHR 

SORTSHR_TV = SORTSHR 

SPISHR_TV = SPISHR 

TPUSHR_TV = TPUSHR 

BASRTL_TV = BASRTL_D56_TV 
BASRTL2_TV = BASRTL2_D53_TV 
BLAS 1RTL_TV = BLAS 1RTL_D53_TV 
COBRTL_TV = COBRTL_D56_TV 
DBLRTL_TV = DBLRTL_D56_TV 
FORRTL_TV = FORRTL_D56_TV 
LIBRTL_TV = LIBRTL_D56_TV 
LIBRTL2_TV = LIBRTL2_D56_TV 
MTHRTL_TV = MTHRTL_D53_TV 
PASRTL_TV = PASRTL_D56_TV 
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PLIRTL_TV = PLIRTL_D56_TV 
VAXC RTL_TV = VAXCRTL_D56_TV 
VAXCRTLG_TV = VAXCRTLG_D56_TV 

DBLMSGMGR = DBLMSGMGR_TV 
EDTSHR_TV = EDTSHR 
TEC032 = TEC032_TV 
TECOSHR = TECOSHR_TV 
VMSRTL = VMSRTL_TV 

DBLRTLMSG = DBL$MSG 
PASMSG = PAS$MSG 
PLIMSG = PLI$MSG 
RPGMSG = RPG$MSG 
SCNMSG = SCN$MSG 
VAXCMSG = DECC$MSG 

5.38 Translated Run-Time Libraries 

V1.0 As part of the OpenVMS AXP kit, Digital provides a set of translated run-time 

libraries. 

Some of the routines in the VAX run-time libraries use the VAX D_floating data 
type for double-precision arithmetic. 

In the translated versions of these libraries, the AXP D56 D_floating data type is 
used by default (where the VAX run-time library used D_floating). This provides 
the full precision of the 56-bit mantissa in VAX D_floating, yielding consistency of 
results at a cost in execution-time performance. 

For a handful of performance-critical math-related libraries, Digital also supplies 
versions of the translated run-time libraries that use the AXP D53 D_floating 
data type for double-precision operations. For these libraries, the D53 forms 
are the default. The D53 forms provide better performance by sacrificing the 
low-order three bits of precision in the mantissa. 

The following translated libraries are provided in D56 form only: 

• BASRTL 

• COBRTL 

• DBLRTL 

• FORRTL 

• LIBRTL 

• LIBRTL2 

• PASRTL 

• PLIRTL 

• VAXCRTL 

• VAXCRTLG 
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5.38.1 

vi.o 


5.38.2 

vi.o 


5.38.3 

vi.o 


The following translated libraries are provided in both D56 and D53 (the default) 
form: 

• BASRTL2 

• BLAS1RTL 

• MTHRTL 

• UVMTHRTL 

If you need to use the D56 form of one of these libraries in order to get more 
consistent results (at a cost of execution-time performance), see Section 5.38.1 for 
instructions. 

Accessing the D56 Form of the Run-Time Libraries 

When you use the run-time libraries, the following happens by default: 

• For BASRTL2, translated BASIC images that use MAT functions on double¬ 
precision data invoke BASIC run-time library routines that use the D53 data 
type. 

• For BLAS1RTL, translated images that invoke BLAS$ functions with 
double-precision floating-point arguments get routines that use the D53 data 
type. 

• For MTHRTL, translated images that invoke MTH$ double-precision floating¬ 
point functions get routines that use the D53 data type. 

• For all others, the AXP D56 floating-point data type is used by default. 

Some users might need the full precision of D56 floating point. However, using 
the D56 routines imposes a very significant performance penalty. To access 
the D56 routines, redefine the run-time library’s logical name to the D56 form, 
as shown in Table 5—5. The logical name can be defined on a per-process or 
systemwide basis, as appropriate for your site. 


Table 5-5 Run-Time Library Logical Names 


Library 

Logical Name 

D56 Name 

BASRTL2 

BASRTL2_TV 

BASRTL2_D56_TV 

BLAS1RTL 

B LAS 1 RTL_T V 

BLAS1RTL_D56_TV 

MTHRTL 

MTHRTL_TV 

MTHRTL_D56_TV 


Problem with Translated Image Environment 

Translated callers to CRF$FREE_VM and CRF$GET_VM will not work properly. 
The translated callers are expecting VAX JSB semantics, but instead, AXP JSB 
semantics are present in the native code (naturally). 

To work around this problem, the translated callers need to use CALL instead of 
JSB. 

Translated VAX BASIC Run-Time Library Notes 

This section describes the limitations and known problems with the OpenVMS 
AXP translated VAX BASIC run-time library (VAX BASIC RTL). The translated 
VAX BASIC RTL is a translated version of the OpenVMS VAX Version 5.4 
VAX BASIC RTL. 
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5.38.4 

vi.o 

5.38.4.1 

VI.O 


All problems and restrictions present in the OpenVMS VAX Version 5.4 release of 
the VAX BASIC RTL exist unchanged in the translated VAX BASIC RTL. These 
items include: 

• Integer errors do not raise the appropriate exceptions. 

For example, a divide-by-zero error does not raise a BASIC error handler but 
causes the translated program to abort. To avoid these problems, explicitly 
test for integer operand error conditions. 

• Array descriptors for H_floating data items will not work. 

For example, passing an H_floating array by descriptor (the default) does not 
pass the array properly to a function or subprogram. Pass H_floating arrays 
by reference to avoid this problem. 

• WHEN block exception processing may not work the same as on VAX systems. 

Translate the program using the /OPTIMIZE=NOSCHEDULE qualifier. 
Programs containing WHEN blocks handle errors but may dump on exit. 

• Explicit calls to LIB$SIGNAL are not handled by a BASIC exception handler 
in a user program. 

• The ON...GOSUB statement does not work properly. 

The control expression is corrupted. Any attempt to access the control 
variable after the ON...GOSUB statement has finished causes the program to 
abort. 

• Taking the identity of large, odd-dimension matrices can result in memory 
management violations. 

Translated VAX C Run-Time Library Notes 

This section describes the limitations and known problems with the OpenVMS 
AXP translated VAX C Run-Time Library (VAX C RTL). 

Functional Restrictions 

The translated VAX C RTL is a translated version of the OpenVMS VAX Version 
5.4 VAX C RTL. All problems and restrictions present in that release of the VAX 
C RTL exist unchanged in the translated VAX C RTL. The following items are 
known restrictions in the functionality of the translated VAX C RTL: 

• The fmod( ) function does not produce correct results for D_FLOAT. 

• D_FLOAT programs that use the SIGFPE signal may not catch all floating¬ 
point exceptions. Translating the program using /FLOAT=D56_FLOAT fixes 
most SIGFPE problems. 

• The sbrk( ) function returns an address that does not match the value 
returned from SYS$EXPREG. 

• D_FLOAT programs that use the HUGEJVAL constant or call the math 
functions (which may return HUGEJVAL) may fail unless they are translated 
with /FLOAT=D56_FLOAT. 

• Under certain circumstances, some math functions (either D_FLOAT or G_ 
FLOAT) may generate a high-performance arithmetic trap exception instead 
of setting errno to ERANGE or EDOM. 
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5.38.4.2 Interoperability Restrictions 

V1.0 The following restrictions apply when the translated VAX C RTL interoperates 

with the native DEC C RTL: 

• The longjmp function cannot be used to transfer control from: 

— A native routine to a translated routine 
— A translated routine to a native routine 

• Memory allocated by malloc, calloc, and so forth must be freed in the same 
context. That is, if a translated routine allocates memory, the free call 
must occur in a translated routine. Allocating memory in a translated 
routine and freeing it in a native routine results in corruption of the heap. 
Likewise, allocating memory in a native routine and freeing that memory in a 
translated routine also corrupts the heap. 

• Signal handlers established by the signal (and related) functions in translated 
routines are not invoked when the signal is raised. Only native signal 
handlers can be used to catch UNIX style signals. 

• The signals SIGEMT, SIGTRAP, SIGIOT and SIGFPE cannot be caught if 
those signals are raised by a translated image. 

• The exec function can be used only to invoke similar images. That is, an 
exec function invoked in a native image cannot execute a translated image. 
Likewise, an exec function invoked in a translated image cannot execute a 
native image. 

• An access violation occurs if vfork is executed in a native image to establish 
the context for a later system call and the system call is then invoked in a 
translated image. 

• File pointers and file descriptors cannot be shared between native and 
translated images. An access violation or file corruption is likely to occur 
if a file is opened in a translated image and a native image attempts to read 
or write using that file pointer. The same results occur if a file is opened in a 
native image and a translated image attempts to read or write using that file 
pointer. 

Programs that perform any of these restricted actions may receive access 
violations or other exceptions. No testing is performed to detect and prevent 
restricted operations from being performed. 

Translated VAX COBOL Programs Supported 

The OpenVMS AXP Version 1.5 operating system supports the execution of 
translated VAX COBOL programs compiled with the VAX COBOL Version 5.0 
compiler (or earlier compilers). 

Programs compiled with the VAX COBOL Version 5.1 compiler are not supported 
by the OpenVMS AXP Version 1.5 operating system. 
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This chapter describes changes to the structure of the OpenVMS documentation 
set and corrections to published documentation. 

6.1 OpenVMS VAX Card Reader, Line Printer, and LPA11-K I/O 
User’s Reference Manual 

V6.1 The following section is to be added to the OpenVMS VAX Card Reader, Line 

Printer, and LPA11-K1/O User’s Reference Manual in Chapter 3, “Line Printer 
Driver,” under the heading Line Printer Driver Device Information. 

DVI$_DEVTYPE and DVI$_DEVCLASS return the device type 
and class names, which are defined by the $DCDEF macro. The 
device type is a value that corresponds to the printer, for example, 
LP$_LP27, LP$_LA11, or LP$_PC_PRINTER. 

6.2 OpenVMS Compatibility Between VAX and AXP 

V6.1 Table 3-2, Availability of Selected Digital Optional Software Products, does not 

include the DEC Fortran compiler. The DEC Fortran compiler has been available 
since the first release of OpenVMS AXP. While the table is not intended to be a 
complete listing, the omission of the DEC Fortran compiler may be misleading. 

6.3 OpenVMS Debugger Manual 

VI.5 In the Command Dictionary section of the OpenVMS Debugger Manual , 

explanatory text for the /FLOAT qualifier should read as follows: 

On VAX systems, displays each examined entity in the F_floating 
type (4 bytes). On AXP systems, displays each entity in the IEEE 
T_floating type (double precision, length 8 bytes). 

6.4 OpenVMS DCL Dictionary 

The following sections pertain to the OpenVMS DCL Dictionary. 

6.4.1 F$GETDVI Item Addition 

V6.1 The DEVICE_TYPE_NAME item was added to the F$GETDVI lexical function. 

It returns a string indicating the name of the device type. This information is in 
online help, but was not included in the printed version of the OpenVMS DCL 
Dictionary . 
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6.4.2 SET DEVICE/SERVED 

V6.1 The note in the Description of the SET DEVICE/SERVED command should read 

as follows: 


_ Note _ 

The DCL command SET DEVICE/SERVED cannot be used under the 
following conditions: 

• In service of a Phase II shadow set virtual unit 

• On devices that are already mounted 

• On system disks 

• On quorum disks 


6.5 Open VMS Delta/XDelta Debugger Manual 

VI.5 The base register default offset for OpenVMS AXP is lOOOOig, not lOOOOOie, as 

documented in the description of the ;X (Load Base Register) command. 

6.6 OpenVMS I/O User’s Reference Manual 

V6.1 The following section should appear in the Terminal Driver chapter of the 

OpenVMS I/O User's Reference Manual. 

6.6.1 Terminal Devices Supported 

Table 6-1 lists the supported terminal devices for the Digital 2100 Server Model 
A500/600 MP and the DEC 2000 Model 300. 


Table 6-1 Supported Terminal Devices 


Terminal 

No.of 

Outout 

Solit 


International 

Interface 

Lines 

Silo 

DMA Speed 

Bus 

Modem Control 

Digital 2100 

Server Model 
A500/600MP 

2 

No 

No 

No 

None 

Full 

Digital 2100 

Server Model 
A500/600MP 1 

4,8 

Yes 

No 

No 

EISA 

Full 

DEC 2000 

Model 300 

2 

No 

No 

No 

None 

Full 

DEC 2000 

Model 300 1 

4,8 

Yes 

No 

No 

EISA 

Full 

1 Optional multiplex serial DIGIboard PC/X™ adapter card, 
in 16, 32, or 64 ports. 

You can daisy chain up to 4 boards in 

one system, resulting 
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6.7 Migrating to an Open VMS AXP System: Porting VAX MACRO 
Code 

VI.5 The /FLAG=INSTRUCTIONS qualifier is documented as flagging instructions 

that may compile correctly but that should be examined anyway for correctness 
on an AXP computer. This applies only to instructions that use absolute 
addresses and not to the instruction MxPR as stated in the description of 
the /FLAG=INSTRUCTIONS qualifier. If the compiler detects the use of 
absolute addresses, the instructions are flagged with the informational message 
CHKABSADR. 

The BUGx instruction is not supported by the compiler. This instruction was 
inadvertently omitted from the list of unsupported instructions in Migrating to 
an OpenVMS AXP System: Porting VAX MACRO Code. 

The restriction that pertained to the qualifiers /DEBUG, /DISABLE, and 
/ENABLE and to the directives .DISABLE and .ENABLE, which is documented 
in Appendixes A and B, has been removed. 

Contrary to the documentation, you can initially enable the TRACEBACK 
and DEBUG options with the /ENABLE directive. You can then turn 
the options off and on with the .DISABLE and .ENABLE directives for 
whichever code sections you want. However, if the /DEBUG qualifier is used 
in the command line, it overrides /ENABLE=(DEBUG,TRACEBACK) and 
/DISABLE=(DEBUG,TRACEBACK), regardless of their position on the command 
line. 

6.8 Migrating to an OpenVMS AXP System: Recompiling and 
Relinking Applications 

VI.5 Migrating to an OpenVMS AXP System: Recompiling and Relinking Applications , 

the OpenVMS Linker Utility Manual , and the description of the BAD_LINK 
message in the Help Message database in the OpenVMS System Messages and 
Recovery Procedures Reference Manual mistakenly describe /NONATIVE_ONLY 
to be the default behavior of the linker. 

The /NATIVE_ONLY qualifier to the LINK command directs the linker not to 
pass along the procedure signature block (PSB) information, created by the 
compilers, in the image it is creating. This is the default behavior of the linker. 

PSB information is necessary if the image you are creating in the link operation 
calls translated VAX images (but not if translated VAX images call it). To 
include PSB information in the image, you must compile the original program 
sources with the appropriate compiler switch (as indicated by the compiler 
documentation) and specify the /NONATIVE qualifier when linking the program’s 
object modules. The image activator uses the PSB information in the image to 
create jacket routines, which allow native AXP images to work with translated 
VAX images. 

6.9 OpenVMS AXP Version 6.1 New Features Manual 

The following notes pertain to the OpenVMS AXP Version 6.1 New Features 
Manual. 
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6.9.1 Error Formatter 

V6.1 Section 3.13 of the OpenVMS AXP Version 6.1 New Features Manual describes 

the new feature of the Error Formatter, ERRFMT, that allows you to send mail 
to the system manager or to another designated user if the ERRFMT process 
deletes itself. You use the new system logical names ERRFMT$_SEND_MAIL 
and ERRFMT$_SEND_TO to control this feature. For complete information 
about defining these logical names, see the OpenVMS System Manager's Manual. 

Job Process Information (JPI) Utility 

The Job Process Information (JPI) utility is one of the System Management 
Examples described in the OpenVMS AXP Version 6.1 New Features Manual. 
Copies of the examples are available on the OpenVMS AXP distribution media in 
the [DOCUMENTATION.V061.EXAMPLES] directory. For information on how to 
access the JPI utility example, see the OpenVMS AXP CD-ROM User's Guide. 

The OpenVMS operating system implementation of the $GETJPI system service 
has imposed a number of constraints and restrictions on JPI Version 2.1. JPI, 
however, has been coded to handle or work around these restraints. Following 
are explanations of these adaptations. 

6.9.2.1 Using the /IMAGENAME Qualifier 

Because the $PROCESS_SCAN system service does not support the IMAGE 
item class, JPI has implemented this feature as a back-end scan. In other 
words, when you specify image name keywords with the /IMAGENAME qualifier, 
JPI first scans processes that match any qualifiers you specify in addition to 
/IMAGENAME; JPI then scans the processes that have been selected for image 
name matches. This search method can add a significant amount of time to the 
overall search. Therefore, it is recommended that you use additional qualifiers 
that narrow the search as much as possible. 

For example, if you want to see which processes in the VMScluster environment 
are currently running the VMSHELP image under the SYSTEM account, issuing 
the first command greatly reduces the search time compared to issuing the second 
command: 

1. In the following example, JPI first selects processes in the VMScluster 
environment with the SYSTEM user name; among these processes, JPI 
then selects processes with the VMSHELP image name: 

$ jpi/username=system/image=vmshelp/cluster 

2. In the following example, JPI must search all of the processes in the 
VMScluster environment for processes with the VMSHELP image name: 

$ JPI/IMAGE=VMSHELP/CLUSTER 

6.9.2.2 Using the /USERNAME Qualifier 

The current implementation of the $PROCESS_SCAN system service on 
OpenVMS VAX systems prohibits an exact match on JPI /USERNAME qualifier 
keywords. Although this restriction applies only to OpenVMS VAX systems, 
because a JPI call might be made in a mixed-architecture environment, the 
restriction applies to all JPI requests using the /USERNAME qualifier, regardless 
of the OpenVMS architecture. 


6.9.2 

V6.1 
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On OpenVMS VAX systems, an exact match on /USERNAME using the 
$PROCESS_SCAN system service is not possible. For example, although 
processes might currently be executing under the SYSTEM user name, if 
you specify to the $PROCESS_SCAN system service (the F$CONTEXT lexical 
function) that you want a search context established for USERNAME=SYSTEM, 
the context actually returns null, indicating no matches. 

To correct this problem, the JPI application has been coded to append a wildcard 
asterisk (*) to each /USERNAME keyword that you supply. In this way, 
$PROCESS_SCAN establishes a search context that includes processes with 
the specified user name or names. This change applies to both OpenVMS VAX 
and AXP systems. 

Because of the addition of the asterisk, however, JPI selects all processes with 
a prefix match on the specified user name. For example, if you specify JPI 
/USERNAME=SYS, JPI displays all processes with user names beginning with 
SYS (which, besides SYSTEM, might include SYSO, SYS1, and so on). 

6.9.2.3 Cluster Usage with the /RCLUSTER or /CLUSTER Qualifiers 

You might need to increase your account BYTLM quota to an artificially high 
value for a clusterwide process scan to succeed. This problem, which is limited to 
OpenVMS AXP Version 6.1, appears only when you request a clusterwide search 
either from a local OpenVMS AXP cluster node with the /CLUSTER qualifier, or 
from a remote OpenVMS AXP cluster node using the /RCLUSTER qualifier. 

In a mixed-architecture cluster, you can circumvent this problem by issuing the 
JPI call either: 

• From one of the OpenVMS VAX nodes within the local cluster 

• To one of the OpenVMS VAX nodes on the remote cluster 

6.9.2.4 Executing JPI Scans on Remote Nodes or Remote Clusters 

JPI Version 2.1 supports the ability to request process scans on nodes that are 
connected through DECnet to the node from which the JPI calls are initiated. 

The remote node or nodes must have both JPI Version 2.0 or higher installed 
and a properly defined DECnet JPI object. (Defining a DECnet JPI object is an 
installation option.) 

If remote calls fail, check the following: 

• Is JPI Version 2.0 or higher installed on the remote node? 

• Is the JPI DECnet object installed on the remote node? 

• If you are specifying access control information with the /RNODENAME or 
/RCLUSTER qualifier, check the following: 

— Is the combination of USERNAME/PASSWORD valid on the remote node? 

— Are there fatal login errors for the remote JPI process on the remote node? 
Check the NETSERVER.LOG file in the default USERNAME directory on 
the remote node. 

— Has the remote account been disabled or has it expired? 

— Does the remote account allow network access for the given day and time? 

— If the remote account is CAPTIVE or RESTRICTED, and a login command 
file is specified in the remote account AUTHORIZE record, the login 
command file must exist, and the caller must have read access to it. 
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• If you are not specifying access control information with the /RNODENAME 
or /RCLUSTERNAME qualifier, check to see that one or both of the following 
are true: 

— Default access control information for the JPI object on the remote node 
is valid. 

When the JPI installation creates the JPI object, the object is created 
without default user ID/password information. Therefore, the DECnet 
Executor defaults apply. If DECnet Executor values for nonprivileged 
user ID and nonprivileged user password do not exist or are not valid (in 
the absence of any supplied access control information or proxy access), 
the remote login fails and JPI issues the following error message: 

JPI-E-NONETLNK Error connecting to NETWORK object at node XXXXXX 

If this error occurs, see your system manager for assistance with defining 
default access information for the JPI object on the remote node or cluster. 

— Proxy information for the issuing NODE::USERNAME exists on the 
remote node. 

Note that a remote JPI call has access only to processes on the remote node or 
cluster to which the target user name has access. For example, if the JPI object 
on the remote node or cluster is defined to use the DECnet account by default, 
and you do not specify access control information with the /RNODENAME or 
/RCLUSTERNAME qualifier, the remote process scan recognizes only processes 
to which the DECnet account has read access on the remote node or cluster. For 
example: 

$ JPI/RNODENAME=F00"TMACK ONETWOBUCKLEMYSHOE":: 

The command in this example uses TMACK as the user name and 
ONETWOBUCKLEMYSHOE as the password to access processes on the remote 
node FOO. JPI will display only those processes on FOO to which this user name 
and password have read access. 

6.10 Open VMS Programming Concepts Manual 

V6.1 The following information should be included in the “System Time Operations” 

chapter of the OpenVMS Programming Concepts Manual. 

The Date/Time Manipulation option provides date/time spelling support for 
four new languages. Users or application programmers can select the desired 
language by defining the logical name SYS$LANGUAGES. The new languages 
and their equivalent names are as follows: 


Language 

Equivalent Name 

Chinese (simplified character) 

Hanzi 

Chinese (traditional character) 

Hanyu 

Korean 

Hangul 

Thai 

Thai 
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Defining Date/Time Spelling 

To define the spelling for the Korean and Thai languages, define 
SYS$LANGUAGES as shown below, prior to invoking LIB$DT_STARTUP.COM: 

$ DEFINE SYS$LANGUAGES HANGUL, THAI 
$ @SYS$MANAGER:LIB$DT_STARTUP 

Predefined Output Formats 

Tables 6-2 and 6-3 list the new predefined date and time format logical names, 
their formats, and examples of the output generated using those formats. 


Table 6-2 Predefined Output Date Formats 


Logical Name 

Format 

Example 

LIB $D ATE_FORM AT_042 

LIB$DATE_FORMAT_043 

LIB$DATE_FORMAT_044 

LIB $D ATE_FORM AT_045 

LIB$DATE_FORMAT_046 

LIB$DATE_FORMAT_047 

!Y4*P!MNBj|!DB0 !WAU 
!Y4^!MNBl!!DB0 !WU 
!Y4^!MNBjd!DB0 !WAU 
!Y4^!MNBj^!DB0 !WU 
!Y4 *d !MNB ^ !DB °J !WAU 
!Y4'd !MNB Q !DB °J !WU 

1994^3^70 (-) 

1994^3^70 Mffl- 
1994^3^70 (—) 

1994^3^70 MM— 

1994^d 3 -*8 7 (-%!) 

1994 >d 3 -Si 7 °J 


_ Note _ 

LIB$DATE_FORMAT_042 and LIB$DATE_FORMAT_043 support the 
DEC Hanzi coded character set. 

LIB$DATE_FORMAT_044 and LIB$DATE_FORMAT_045 support the 
DEC Hanyu coded character set. 

LIB$DATE_FORMAT_046 and LIB$DATE_FORMAT_047 support the 
DEC Hangul coded character set. 


Table 6-3 Predefined Output Time Formats 

Logical Name 

Format 

Example 

LIB$TIME_FORMAT_021 

LIB$TIME_FORMAT_022 

LIB$TIME_FORMAT_023 

!MIU!HB2Bd!MB^!SB# 

!MIU!HB20f!MB5d!SB# 

!MIU !HB2 -*1 !MB & !SB i 

±M3Bd3^6# 

±^3Bf3^6# 

-2-^ 3 A 1 3-r6i 


_ Note _ 

LIB$TIME_FORMAT_021 supports the DEC Hanzi coded character set. 
LIB$TIME_FORMAT_022 supports the DEC Hanyu coded character set. 
LIB$TIME_FORMAT_023 supports the DEC Hangul coded character set. 
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Thus, to select a particular format for a date or time, or both, you can define the 
LIB$DT_FORMAT logical name using the following logicals: 

• LIB$DATE_FORMAT_72/27i, where nnn can range from 001 to 047 

• LIB$TIME_FORMAT_7mn, where nnn can range from 001 to 023 

6.11 Open VMS AXP Version 1.5 Release Notes 

V6.1 Section 4.6.1 of the OpenVMS AXP Version 1.5 Release Notes stated that the 

/EXACT_ORDER qualifier was available for BACKUR This was an error; the 
/EXACT_ORDER qualifier is available for OpenVMS AXP Version 6.1. 

6.12 OpenVMS RTL String Manipulation (STR$) Manual 

V6.1 The Bookreader version of this manual incorrectly lists the passing mechanism 

of the start-position argument in the STR$POSITION routine. The correct 
passing mechanism is by reference. This will be corrected in a future version of 
the Bookreader file. 

6.13 OpenVMS System Manager’s Manual 

V6.1 The appendix that lists and describes the files on a system disk, formerly located 

in the OpenVMS System Manager's Manual , has been moved into DCL Help. 

To view this information, enter the following command: 

$ HELP SYSTEM_FILES 

To extract the list of system files to an output file in your directory, use the 
following command, where file-name represents the name of the output file: 

$ HELP/0UTPUT=file-/iame SYSTEM_FILES 

6.13.1 New SYSMAN Commands: IO SET EXCLUDE and IO SHOW EXCLUDE 
Missing 

V6.1 A new feature in SYSMAN allows you to permanently exclude certain devices 

from autoconfiguration. 

Some SCSI devices, especially optical devices, do not fully follow the SCSI 
standard. As a result, the system autoconfigures these devices as disks. This 
autoconfiguration prevents you from using an alternate class driver to manage 
the device. Excluding the device as a disk allows you to configure it later in 
startup (in SYCONFIG.COM). 

Autoconfiguration is not a problem on standalone systems on 
which volume shadowing is not running, because you can use the 
IO AUTOCONFIGURE/EXCLUDE command. In a cluster, or with volume 
shadowing turned on, you must configure all devices that might be disks much 
earlier in the boot process, well before SYCONFIG.COM is invoked. However, 
you can use the new permanent exclusion list created with IO SET EXCLUDE in 
both clustered and nonclustered systems, and with or without volume shadowing. 

6.13.1.1 IO SET EXCLUDE 

Sets the permanent exclusion list to be used when configuring devices 
automatically. 
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Format 

10 SET EXCLUDE = (device_name) 

Parameter 

device_name 

Specifies the device type to be excluded from automatic configuration. Use 
valid device names or mnemonics that indicate the devices to be included in 
the permanent exclusion list. You can specify wildcards. 

Description 

Sets the permanent exclusion list to be used when configuring devices. 

Example 

SYSMAN> 10 SET EXCLUDE=(DKC500,DKD*) 

This example specifies that DKC500 and all DKD devices are not to be 
autoconfigured. 

Refer to the /SELECT qualifier of the SYSMAN command IO 
AUTOCONFIGURE in the OpenVMS System Management Utilities Reference 
Manual for additional examples that show how to specify device names. 

6.13.1.2 10 SHOW EXCLUDE 

Displays the permanent exclusion list used in the autoconfiguration of devices. 

Format 

IO SHOW EXCLUDE 

Description 

The IO SHOW EXCLUDE command displays the permanent exclusion list on 
the console. This list is used in the autoconfiguration of devices. 

Example 

SYSMAN> IO SHOW EXCLUDE 

%SYSMAN-I-IOEXCLUDE, the current permanent exclusion list is: DKC500,DKD* 

This example shows the permanent exclusion list used in the 
autoconfiguration of devices; the current list contains DKC500 and all DKD 
devices. 

6.14 UETP Documentation Relocated 

V6.1 In previous OpenVMS releases, the documentation for UETP (the User 

Environment Test Package) software was provided in the OpenVMS upgrade 
and installation manuals. With this OpenVMS release, UETP documentation has 
been moved to the OpenVMS System Manager's Manual: Tuning, Monitoring, 
and Complex Systems. 

6.15 Volume Shadowing for OpenVMS 

V6.1 The following corrections apply to Volume Shadowing for OpenVMS : 

• Formerly, per-disk volume shadowing licenses were available only for AXP 
computers. With the release of OpenVMS VAX Version 6.1, volume shadowing 
licenses are available on a per-disk basis also for VAX computers. 

This information was omitted from Volume Shadowing for OpenVMS , which 
describes per-disk licensing as an AXP only feature. 
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• Two volume shadowing parameters, SHADOW_REMOVE_l and SHADOW_ 
REMOVE_2, were inadvertently omitted from Volume Shadowing for 
OpenVMS. These parameters are only for OpenVMS Engineering use. 


6-10 




7 


Customer Log Desk (CLD) Problems Fixed in 

OpenVMS AXP Version 6.1 


This chapter describes some OpenVMS AXP Version 1.5 problems that have been 
fixed in OpenVMS AXP Version 6.1. These Version 1.5 problems were reported 
to the Customer Log Desk (CLD). The fixes, in addition to being included 
in the Version 6.1 kit, are available for Version 1.5 through the Customer 
Support Center (CSC) to those customers whose software contracts or warranty 
agreements provide this service. 

7.1 BADPPFLREFCNT Crashes 

The system manager observed crashes with the bugcheck code 
BADPPFLREFCNT, because the code in the module PAGEFILE.MAR was 
incorrectly testing for a fatal error. This problem seems to have been aggravated 
by running POSIX Version 1.0 on OpenVMS AXP Version 1.5 with multiple 
paging files installed for the system. 

This problem affected the image VM.EXE. 

7.2 DEC 3300 AXP — Headphone Jack Did Not Work 

On a DEC 3000 Model 300 system, you could not access DECsound through the 
handset. The internal speaker worked fine, but the handset could not be heard. 

This problem affected the image SODRIVER.EXE. 

7.3 DEC C Run-Time Library 

The following problems affected the image DECC$SHR.EXE. 

7.3.1 Virtual Memory Corruption upon Opening a File 

When opening a file in DEC C record-mode, one or more bytes of memory not 
allocated to the record area were overwritten with carriage control data. The 
carriage control data was bytes containing the value 10 (hex 0x0a). 

If the length of the record was a multiple of 8 bytes, this defect tended to corrupt 
the memory structures used by the heap manager (routines malloc() and free()). 
In one occurrence, it caused only the first 10 bytes of data return from calloc() 
to be initialized. If the length of the record was not a multiple of 8 bytes, or if 
the application called setbuf() to specify the record buffer, the symptoms of the 
memory corruption were indeterminate. 

In one scenario, the uninitialized memory returned by calloc() resulted in 
a subsequent open failing with vaxc$errno set to RMS$_ACC and the RMS 
secondary status (fab$l_stv) set to SS$_ACCVIO. 

This problem affected fixed-length record files and variable-length record files, 
but not UNIX style stream files. 
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7.3 DEC C Run-Time Library 

7.3.2 longjmp Function Improperly Restored Floating-Point Registers 

The longjmp() function did not properly restore floating-point registers F2 
through F9. This problem affected programs that directly called longjmp() as 
well as those that called system(), any of the exec*() routines, or vfork(). 

The effect of this problem was that variables declared as float or double did not 
contain the same value after the call as before the call. 

7.3.3 printf() Function — ACCVIO for Format %016.16x 

The printf() function produced an access violation when processing %x format 
specifiers with a precision greater than 10. 

7.3.4 Condition Handlers Not Invoked When Compiled /OPTIMIZE 

For some programs compiled /OPTIMIZE that attempted to establish a condition 
handler by means of a call to LIB$ESTABLISH, the programs executed as if the 
call to LIB$ESTABLISH had not been made at all. 

This problem also appeared when using the TRY, CATCH, RAISE macros from 
<exc_handling.h>, which are layered on top of LIB$ESTABLISH. 

7.3.5 argc was Incorrect for C Programs Linked Against COBOL Library 

If a C main program was linked with object modules written in COBOL, the value 
of argc was exactly twice the expected value. 

7.3.6 memcmpO and memchr() Functions — ACCVIO for String at the End of 
a Page 

When comparing strings that ended at the hardware memory-page boundary, the 
memcmp() and memchr() functions loaded one character too many, causing an 
ACCVIO. The extra character was not used in the comparision, so if the function 
finished, the result of the function was correct. 

7.3.7 memchr() Function — Failure for Characters 128-255 

The memchr() function performed signed byte comparison instead of unsigned 
byte comparison. As a result, characters in the range 128-255 were not processed 
correctly. 

7.3.8 Undefined Symbols DECC$RECORD_READ and DECC$RECORD_WRITE 

The symbol definition was missing for symbols DECC$RECORD_READ and 
DECC$RECORD_WRITE. 

7.3.9 ASTs Enabled by File Open 

In programs that performed file opens with ASTs disabled, the open did not 
successfully complete, and so a subsequent I/O operation on the file failed, 
usually with vaxc$errno set to RMS$_EOF (end of file detected). 

7.3.10 Seek to End of Buffer Not Handled Properly 

Programs that accessed stream files and performed a seek operation that 
corresponded exactly to the end of the buffer (lseek() with a direction of SEEK_ 
END) reset the buffer to be aligned with the next seek after the SEEK_END. As 
a result, subsequent reads or writes occurred at the wrong place in the file. 

The default buffer size was 32768 and so programs with a problem were generally 
those that seek to a multiple of 32768 bytes. 
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7.3.11 Seek Past the End of File 

In programs that performed a seek past the end of the file, the buffer was 
improperly positioned, and further operations within the same buffer yielded 
incorrect positioning. 

7.3.12 scanf Function Fails for Value INT_MIN (-2147483648) 

When the scanf function converted the value -2147483648 from text form to 
integer, -2147483648 was treated as an overflow condition (and hence invalid 
input). This could occur when processing the format specifier of %d or %i. 

7.3.13 Memory Corruption in Executive Routines 

Executive routines could corrupt virtual memory so that a subsequent malloc() or 
calloc() call results in an ACCVIO. 

7.3.14 argc/argv Problem with C++ Static Initialization 

In C++ programs that perform static initialization and DEC C programs 
that make direct calls to DECC$CRTL_INIT (or VAXC$CRTL_INTI) from a 
contribution to the LIB$INITIALIZE PSECT, argc was zero and argv was the null 
pointer. 

7.4 Custom CLIs Unable to Create Permanent Privileged Vectors 

Customer-written command language interpreters (CLIs) and Digital products 
using custom CLIs were unable to create rundown vectors or user-written system- 
service vectors that survived image-rundown. This could make some product 
functions unusable. 

This problem affected the image IMAGE_MANAGEMENT.EXE. 

7.5 Cluster Server Process 

In multiprocessor systems, the cluster server process generated an access 
violation and looped. 

This problem affected the image CSP.EXE. 

7.6 DEC COBOL Run-Time Library 

All of the fixes available in the CLD kit AXPCOB04_015 are included in this 
release. The following is a partial list of those fixes. 

7.6.1 Changes in ACCEPT and DISPLAY Behavior 

If your application uses the Digital extensions to ACCEPT and DISPLAY: 

• The restrictions in DEC COBOL VI.0 on the ACCEPT and DISPLAY 
statements have been removed. These restrictions limited the use of the 
OpenVMS Screen Manager utility (SMG) and Curses directly from your 
application, and also limited the ability to display control sequences. 

• The screen is no longer cleared when the application starts. 
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7.6.2 READ REGARDLESS of a Locked Record 

When your application read a locked record from a sequential file using READ 
REGARDLESS, the returned status was always successful. Now the proper 
status (90) is returned. 

7.6.3 Linking DEC COBOL and non-DEC COBOL modules 

When you link DEC COBOL modules together with non-DEC COBOL modules 
that contain LIB$INITIALIZE program section (psect) contributions, your 
application could produce unexpected results. 

DEC COBOL uses the VMS LIB$INITIALIZE mechanism to set up the run-time 
environment for the CALL variable-name and extended ACCEPT and DISPLAY 
functionality. DEC COBOL contributes the COB_NAME_START routine to the 
LIB$INITIALIZE psect, and this routine must be invoked before any CALL, 
ACCEPT, or DISPLAY statements are performed. Therefore, if your non-DEC 
COBOL modules contribute LIB$INITIALIZE routines that call DEC COBOL 
routines, you should change your link command in the following manner: 

$ LINK/EXE=flame SYS$SHARE:STARLET/INCL=C0B_NAME_START, - 
_$ yourjnodules ,... 

Previous versions of the DEC COBOL RTL specified an incorrect psect alignment 
for the LIB$INITIALIZE contribution. This caused a problem if there were other 
LIB$INITIALIZE contributions; in many cases, this misalignment resulted in the 
DEC COBOL LIB$INITIALIZE routine never being invoked. Hence, all CALL 
variable-name statements failed and all ACCEPT and DISPLAY extensions were 
ignored. 

7.6.4 Variable-Length Records in Sequential Files 

If your application created a SEQUENTIAL file whose file description contained 
the RECORD VARYING phrase and whose OPEN statement did not contain an 
ALLOWING phrase, the resulting file had a Longest Record [length] of zero (0). 
The Longest Record value indicates the length of the longest record in the file and 
can be viewed using the ANALYZE/RMS command. 

If you later opened the file for EXTEND access and wrote additional records, 
the resulting file sometimes had an invalid Longest Record value. DEC COBOL 
does not use the Longest Record value, but the value may be used by other 
applications. 

The Longest Record value is now set and maintained correctly when you create 
and modify the file. 

7.7 Condition Handling 

The following problems affected the image EXCEPTION.EXE. 

7.7.1 Condition-Handling Failure When Program Interrupted by an AST 

When a register frame procedure (generated by a compiler) was interrupted by 
an AST, the OpenVMS Condition Handling facility prematurely terminated the 
call chain. Therefore, if the AST routine raised a condition (for example, by 
calling LIB$SIGNAL), the OpenVMS Condition Handling facility failed to find all 
declared condition handlers, resulting in an improperly handled exception and an 
image exit. 
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An example of this scenario occurred with the C Run-Time Library alarm() 
function. If the alarm became due while the program was executing in the 
context of a register frame procedure, the program was forced to exit with an 
improperly handled exception. 

7.7.2 Corruption of Floating-Point Registers 

The OpenVMS Condition Handling facility incorrectly restored floating-point 
registers on procedure unwind. 

Another symptom of this problem was that a nested exception (for example, 
LIB$SIGNAL called from a condition handler) with a register frame procedure in 
the call chain erroneously caused the image to exit. 

7.8 Debugger Problems 

The following problems affected the images DEBUG.EXE, DEBUGSHR.EXE, 
DEBUGUISHR.EXE, and DBGTBKMSG.EXE: 

• The debugger hung when trying to step over an IMB instruction. 

• The debugger hung when activated through ANALYZE/PROCESS. 

• A debugger ACCVIO with FORTRAN shared common data. 

• A debugger memory leak associated with "when" conditional expression 
evaluation. 

7.9 DECthreads Problems 

The following problems affected the images CMA$RTL.EXE and CMA$OPEN_ 
RTL.EXE. 

7.9.1 Ada TASKING_SERVICES.QIOW — Performance Degradation 

Ada programs that used the TASKING_SERVICES package, specifically 
TASKING_SERVICES.QIOW, experienced unacceptable performance on 
OpenVMS AXP Version 1.5. 

7.9.2 DECthreads Timed Waits Occasionally Did Not Time Out 

The DECthreads timed condition wait routines (cma_cond_timed_wait, pthread_ 
cond_timedwait) occasionally failed and never timed out. This was sometimes 
experienced as an Ada DELAY statement that never completed. 

7.10 DECwindows Common Transport 

DEC windows common transport was missing some VOLATILE attributes that 
could cause processes to hang on SMP systems using LAT transport. 

There was at least one place in the DECwindows common transport where 
variables not declared with the VOLATILE attribute caused SMP systems to have 
hung processes. These processes hung while waiting for the queue interlock to be 
cleared, although the bit was actually already clear. 

This problem occurred with the LAT transport, because it was possible for the 
user process to be running on one CPU while the XTDRIVER had the queue 
locked on another CPU. None of the other transports have this problem because 
they are not partitioned with an OpenVMS device driver like the LAT transport. 

This problem affected the image DECW$TRANSPORT_COMMON.EXE. 
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7.11 DECwindows Display — Pixels Missing on Lines 

The following problems affected the image DECW$SERVER_DDX_GX.EXE. 

• When creating many windows and using XDrawlines, there are pixels where 
they should not be written. When you drew a horizontal line in the included 
test program, an extraneous pixel appeared above the second endpoint about 
40% of the time. 

• On a system with an HX graphics card, the endpoint of a line was sometimes 
drawn several pixels above where it should be. The endpoint was being 
drawn with respect to window-relative instead of screen-relative coordinates. 

7.12 DKDRIVER Problems 

The following problems affected the image DKDRIVER.EXE. 

7.12.1 CHECK_HBS Routine 

The CHECK_HBS routine determines whether a device supports host-based 
shadowing and sets the NOFE (No forced error) bit accordingly. For DEC 7000 
systems, this routine did not work. The routine reads long operations in a loop 
until one works. It allocates only one buffer for SCSI commands and reuses it 
each time through the loop, updating only the length. The PKZDRIVER requires 
a fresh buffer for every operation. This caused the PKZDRIVER to always use a 
0 data length and the readlong operation aways failed. 

7.12.2 Data Security Erase Function 

The Data Security Erase function did not segment long data transfers as the read 
and write operations do, which caused crashes for data lengths longer than 127 
pagelets. 

7.13 DSSI Device — File Corruption 

The user saw file corruption due to page faulting a global section mapped 
to a user process while I/O was outstanding to a DIGITAL Storage Systems 
Interconnect (DSSI) device. 

This problem affected the image PIDRIVER.EXE. 

7.14 End-of-File Errors on Very Large Files 

All applications got SS$_ENDOFFILE errors when attempting to access certain 
virtual blocks within extremely large files that had contiguous extents greater or 
equal to 8,388,608 (2**24) disk blocks. 

It was possible to create such files on a stripe set. 

This problem affected the image IO_ROUTINES.EXE. 

7.15 Error Logging — Crash 

The system crashed with an INVEXCEPTN error when logging error information. 
This problem affected the image PKTDRIVER.EXE. 
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7.16 Execlet/Driver Loading on Multiprocessors 

On multiprocessor systems, an execlet image, typically a driver, could fail to 
load correctly or could crash the system. This was caused by the failure of the 
executive loader to flush temporary virtual address mapping used during certain 
loading operations from the translation buffers on all CPUs in the system. The 
result of the stale translation buffer entries was that the loader did not load the 
execlet code or data at the correct virtual address. 

This problem affected the images SYSTEM_PRIMITIVES.EXE and SYSTEM. 
PRIMITIVES_MIN.EXE. 

7.17 FILCNTNONZ Bugcheck — RO Contained IVCHAN Status 

On OpenVMS AXP Version 1.5-1H1, the system crashed with the FILCNTNONZ 
bugcheck. RO contained 0000013C, which is the failure code for: 

%SYSTEM-F-IVCHAN, invalid I/O channel 

This problem affected the image IMAGE_MANAGEMENT.EXE. 

7.18 FORTRAN — Corruption in Writable Global Sections or 
Installed Writable Commons 

In an application that used a FORTRAN common installed in the system via 
INSTALL CREATE /WRITE/SHARE, data written to the installed common was 
missing. The data got lost when sufficient activity on the system caused the data 
in the writable global section to be written to its backing store in the image file. 

7.19 DEC Fortran Run-Time Library 

The following problems affected the image DEC$FORRTL.EXE. 

7.19.1 Failure to Backspace Correctly 

The BACKSPACE statement failed to move back one record when a sequential 
unformatted file was opened READONLY The BACKSPACE statement either 
failed with %FOR-F-BACERR (-RMS-E-EOF, end of file detected), or it was 
incorrectly positioned within the file so that a subsequent READ statement read 
the wrong data. 

7.19.2 Failure to Calculate the Correct Record Length 

The INQUIRE statement returned the wrong record length in the RE CL variable 
for direct access, unformatted files. The record length for those kinds of files 
should be expressed in longword units, not byte units. When the RTL converted 
the value from bytes to longwords, it used an incorrect algorithm. 

7.20 F$SEARCH — DECnet Links Left Active After Nonwildcard 
Search 

If a wildcard was not used in the file specification, an F$SEARCH lexical function 
to a file at a remote node did not disconnect the link to the remote node after 
returning the result. 

This problem affected the image DCL.EXE. 
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7.21 Image Activation — Multi-Instance 

Multiple use of non-reentrant libraries within a single process was not allowed. 
This problem affected the image IMAGE_MANAGEMENT.EXE. 

7.22 Keyboard Problems 

The following keyboard problems affected the images IKDRIVER.EXE and 
INDRIVER.EXE: 

• Pressing two function keys in a row while pressing the CAPS LOCK key 
caused the CAPS LOCK LED to get out of sync. 

• With the CAPS LOCK key held down, pressing two function keys (for 
example, FI and F2) at the same time caused one of the keys to be 
autorepeated continuously. The only way to stop the repetition was to 
end the session. 

• With the Lock-Down Modifier locked down, changing the keymap to any 
keymap caused KP_3 to be autorepeated continuously. Pressing KP_3 stopped 
the repetition. 

• Exiting from the DECwindows session while Mode Switch was locked down 
(with the Lock-Down-Modifier binding) caused the mouse and the keyboard 
to freeze during login. The only way to recover was to shut down and reboot. 
Restarting the server did not solve the problem. 

7.23 LIBRARIAN Performance Problem on DELETE and REPLACE 

The LIBRARIAN performed poorly when deleting or replacing modules in a 
library. 

This problem affected the image LBRSHR.EXE. 

7.24 Mailbox Driver — Calls to Inaccessible AST Parameters 

A Read or Write QIO to the mailbox driver that contained an inaccessible 
AST parameter caused the system to crash in EXE$ABORTIO. The calls in 
MBDRIVER to EXE$READCHK and EXE$WRITECHK did not include the PCB 
address, which caused random data to be used as the AST parameter. 

This problem affected the image SYSDEVICE.EXE. 

7.25 Bad Memory Above 512 Megabytes 

The appearance of a bad page of memory above the 512-megabyte mark could 
result in a “kernel stack not valid” halt during booting. This was caused by 
the failure to remap the appropriate number of tested bitmap pages. It was 
only observed on DEC 7000 or DEC 10000 systems running Version 3.0 console 
firmware. 

This problem affected the image SYSBOOT.EXE. 
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7.26 Modem Signals and YRDRIVER 

Modem signals being reported by the YRDRIVER were not correct. Also, the 
two modem transmit signals, DTR (Data Terminal Ready) and RTS (Request To 
Send), could not be set to the ON state independently, but only at the same time. 

This problem affected the image YRDRIVER.EXE. 

7.27 Overlaid Program Sections — Multiple Fixups to One Location 

Data in overlaid program sections that made external references to shareable 
images appeared to be incorrect. 

When linking an image that contained overlaid program sections with 
contributions from different modules that referenced global symbols, the linker 
generated fixup information for each reference, even though the references might 
be to the same location. When the image was activated, all fixups to that location 
were applied and the information was incorrect. 

This problem affected the image LINKER.EXE. 

7.28 PC/PS Passed to an AST Routine Was Sometimes Wrong 

When multiple ASTs were queued for the same mode simultaneously, the PC/PS 
passed to the AST routine could be incorrect. This caused a difference in A Y 
behavior, because an application’s A Y attention AST was looking at the mode field 
in the PS and getting the wrong answer. 

This problem affected the image PROCESS_MANAGEMENT.EXE. 

7.29 PIXSCAN Priority Boosts 

In some cases, a low-priority computable process did not receive a PIXSCAN 
priority boost, and the process was blocked from executing. 

This problem affected the image VM.EXE. 

7.30 PL/I TRANSLATE Instruction 

PL/I TRANSLATE() BIF did not accept 8-bit characters. 

This problem affected the image DPLI$RTLSHR.EXE. 

7.31 POSIX Child Hung System While Locking Pages 

There was an IPL 8 hang within a POSIX child process attempting to lock pages. 
Either the working set for the child process seemed too low or the system hung 
when the child process attempted to lock pages in the working set. 

This problem affected the image PROCESS_MANAGEMENT.EXE. 

7.32 PRINT/PASSALL Corrupted Files 

Printing a file with the /PASSALL qualifier generated repeated characters in the 
output data stream. 

This problem affected the images PRTSMB.EXE and SMBSRVSHR.EXE. 
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7.33 PTD$ Routines — Global Event Flags Caused a Process 
ACCVIO 

Use of global event flags to the PTD$ services caused problems. A set of registers 
were being corrupted, resulting in an ACCVIO in EXE$ASTDEL. 

This problem affected the image PTD$SERVICES_SHR.EXE. 

7.34 Extending QUOTA.SYS on an AXP System in a VMScluster 
System 

If you attempted to extend your QUOTA.SYS file from an OpenVMS AXP node in 
a VMScluster system, the information regarding this extent was not propagated 
to other nodes in the cluster; for example, when you performed a disk quota 
rebuild operation from that node, and you attempted to add information about 
more users than there was room for in the existing QUOTA.SYS file. 

The problems experienced were: 

• From all other nodes in the VMScluster system, if you issued an 
ANALYZE/DISK command for the disk in question, you received errors 
in the following form: 

%ANALDISK-W-READQUOTA, error reading QUOTA.SYS, VBN <x> 

-SYSTEM-W-ENDOFFILE, end of file 

• From all other nodes in the VMScluster system, if you issued the following 
SYSMAN command, only the information for users held in the preextended 
quota.sys file was displayed: 

SYSMAN> diskquota show * 

These problems affected the image F11BXQP.EXE. 

7.35 SCSI Controller Chips — Undetected Parity Errors 

Because of a possible race condition on some 53C94 SCSI controller chips, it was 
possible to get undetected parity errors while writing directly to the data in a 
first-in/first-out (FIFO) mode. As a result, commands containing errors could 
be sent to a SCSI device, which could cause undetected disk corruption. This 
situation occurred only on DEC 3000 systems. 

This was a hardware problem. 

7.36 SCSI Devices using LUNs — Incomplete Cleanup after Bus 
Reset 

Under certain unusual circumstances, the OpenVMS AXP Version 1.5 SCSI bus 
port driver for DEC 3000 systems failed to clean up all operations on nonzero 
LUNs following a bus reset. 

This problem affected the image PKCDRIVER.EXE. 
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7.37 SET TERMINAL/PROTOCOL=NONE 

The DCL command SET TERMINAL/PROTOCOL should be a NOOP on 
OpenVMS AXP systems, but a process with privileges executing that command 
caused an ACCVIO. 

This problem affected the image SET.EXE. 

7.38 SORT Failed When Sorting User-Defined Data Types 

SORT failed with an access violation while sorting a user-defined data type with 
a user-supplied comparison routine. Parameters to the user’s comparison routine 
were being passed incorrectly by SORT. 

This problem affected the image SORTSHR.EXE. 

7.39 SSRVEXCEPT When Monitoring a Process During Swapping 

While monitoring a process under heavy load, the monitored process was 
swapped out and back in. Once it got swapped back in, the system crashed with 
a SSRVEXCEPT at EXE$READ_PROCESS_C+434. 

This problem affected the image PROCESS_MANAGEMENT.EXE. 

7.40 STR$DIVIDE Routine — Access Violation 

If the result of a division in STR$DIVIDE was exactly zero, an access violation 
could occur (due to an uninitialized variable) when padding the result string with 
leading zeros. 

This problem affected the image LIBRTL.EXE. 

7.41 TTA1 Terminal Port Hang and Data Corruption 

The TTA1 port would hang in the middle of a print job, because it sent a corrupt 
DMA data packet to the printer. 

This problem affected the image YRDRIVER.EXE. 

7.42 TTDRIVER — Multiple FORK_AND_WAIT 

A node could hang in cluster if multiple FORK_AND_WAITs were queued. 

This problem affected the image TTDRIVER.EXE. 

7.43 VMScluster Problems 

There were a number of problems with the VMScluster environment. They 
affected the image FXDRIVER.EXE, which was the device driver for the DEMFA 
on DEC 7000 and 10000 systems. 

• When the system parameter PE3 was set to 1 to enable FDDI clustering, the 
system hung during startup. 

• When a DEMFA has exactly 16 packets queued to it, there was a remote 
possibility of a system crash with certain packet sizes on transmit. 

• Multicast mode 

— Multicast mode was enabled by default. The counter for unrecognized 
multicast packets in SDA then went up faster than might be expected. 
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- On completing a multicast transmit, an internal counter for the user 
(which was displayed in SDA as counters for the UCB) was incremented 
by 80000000 (hex) bytes too many. 

• A problem occurred in fatal error handling, where transmit and receive 
processing was done when the device was not running, resulting in a system 
crash. 

• DECnet failed to start if DEMFA Version 2.0 firmware was installed, because 
DEMFA Version 2.0 firmware changed the size of one of the commands. 

7.44 Volume Shadowing 

The following problems affected Volume Shadowing for OpenVMS. 

7.44.1 Page or Swap I/O Failed on SCSI Disks 

Customers who ran shadowing on SCSI disks experienced crashes and hangs 
when doing page or swap I/O. The shadowing driver copied the same hardwired 
KPB pointer into all of the child IRPs for the various shadow set members, which 
caused the KPB and its associated stack to be shared by multiple simultaneously 
active threads of execution. 

This problem affected the images VM.EXE and SYSTEM_PRIMITIVES.EXE. 

7.44.2 Failover on Shadow Set Members 

Devices that were members of shadow sets would not fail over to a valid 
secondary path when the primary path failed. This could cause one of the 
following symptoms: 

• The virtual unit entered (and remained) in mount verification until either 
MVTIMEOUT expired or the primary path returned. 

• Members of shadow sets were removed because they failed a PACKACK after 
twenty retries. 

This problem affected the images SHDRIVER.EXE and DUDRIVER.EXE. 
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DECevent utility, 4-12 
DEC Fortran compiler, 6-1 
DEC Fortran Run-Time Library 
bug fixes available, 5-27 
CLD problems fixed, 7—7 
format changes for LIST-DIRECTED floating 
point output, 5-27 

format changes to formatted floating-point 
output, 5—27 

new limit on open files, 5-27 
DECmigrate for OpenVMS AXP VAX Environment 
Software Translator utility (VEST) 

See VEST 
DECnet, 3-9 
connections 

auditing, 4—10 
host-based routing, 4-12 
proxy services, 4-10 
restrictions, 3-9 
DECnet/OSI 

DECdtm services, 3-9 

error messages while upgrading, 3-13 

full names 

support in mixed-architecture VMScluster 
system, 4-12 

removing field-test software, 3-12 
DECnet Phase V 
See DECnet/OSI 
DECsound 

headphone jack 

CLD problem fixed, 7-1 
DECthreads 

CLD problems fixed, 7—5 
erroneous thread terminations, 5-19 
.H file support, 5-39 

potential DEC C RTL problem with calls to 
LIB$FIND_IMAGE_SYMBOL, 5-19 
potential hang on program abort, 5-19 
DECTPU SET built-ins 

WIDGET_CONTEXT_HELP keyword, 2-7 
DEC TRNcontroller 700, 1-6 
DECwindows change 

VIRTUALPAGECNT requirements, 3-10 
DECwindows common transport 
CLD problems fixed, 7-5 


DECwindows display 

CLD problems fixed, 7-6 
DECwindows mail 
Audio Editor, 1—1 

DECwindows Motif for OpenVMS AXP 
using EVE in a DECterm emulator, 2—6 
Default protection 

for disk devices, 3-30 
/DEFAULT qualifier, 3-34 
DEFINE/SYSTEM command, 1-9 
Delta/XDelta debugger 

using to debug translated images, 5-16 
Denying access to objects with UIC [0,0], 3-28 
DEPOSIT/TYPE command restriction 
OpenVMS Debugger, 5-17 
Device drivers 

written in C, 4-14 
Device interrupt timeouts 
changes to handling, 5-23 
Device recognition 
dynamic, 4-15 
Devices 

excluding, 6-8 
Device support 

debugging device drivers, 5-25 
loading drivers on AXP, 4-14 
Step 2 driver interface, 5-20 
user-written drivers, 5-20 
writing drivers in C, 5-20 
writing drivers in Macro-32, 5-20 
DEVICE_TYPE_NAME item code, 2-3 
DIAGNOSE command, 4-12 
DIFFERENCES command, 2-1 
Digital 2100 Server Model A500/600MP, 1-4 
Digital Portable Mathematics Library 
See DPML 

Digital Product Performance Program, 3-1 
participating in, 3-1 
DIRECTORY command, 2-1 
/DISABLE qualifier, 6—3 
Diskettes 

serving, 1-4 
Disks 

change in default access, 3-30 
Disk space 

preallocated for audit log file, 3—31 
DISMOUNT/CLUSTER command 
volume shadowing restriction, 3—46 
Dismount utility (DISMOUNT) 

in mixed-architecture VMScluster system, 4—13 
DKDRIVER 

CLD problems fixed, 7-6 
restriction removed, 1—5 
Documentation comments, sending to Digital, iii 
Documentation corrections 

Migrating to an OpenVMS AXP System: Porting 
VAX MACRO Code, 6-3 
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Documentation corrections (cont’d) 

Migrating to an OpenVMS AXP System: 

Recompiling and Relinking Applications , 
6-3 

OpenVMS AXP Version 1.5 Release Notes , 6-8 
OpenVMS AXP Version 6.1 New Features 
Manual , 6-3 

OpenVMS Compatibility Between VAX and AXP , 
6-1 

OpenVMS DCL Dictionary , 6-1 
OpenVMS Debugger Manual , 6-1 
OpenVMS Delta/XDelta Debugger Manual , 

6-2 

OpenVMS I/O User’s Reference Manual , 6-2 
OpenVMS Programming Concepts Manual , 6-6 
OpenVMS RTL String Manipulation (STR$) 
Manual , 6—8 

OpenVMS System Manager’s Manual , 6-8 
OpenVMS VAX Card Reader, Line Printer, and 
LPA11-K I/O User’s Reference Manual , 

6-1 

DPML 

mathematical operations not supported, 5-37 
Drivers 

loading on AXP, 4-14 
DSSI device file corruption 
CLD problem fixed, 7—6 
Dumpfile failover 
shadowing, 4-13 
Dynamic device recognition, 4—15 
Dynamic load balancing, 4-12 
Dynamic system recognition, 4—15 

E_ 

Edit/FDL utility (EDIT/FDL), 5-27 
EDIT command, 2-2 

default editor changed to TPU, 2-2 
/EDT qualifier, 2-2 

used with DCL command procedures, 2-2 
overriding the default editor, 2-2 
EDIT/FDL command, 2-2 
Editors 

See EDT editor 
See EVE editor 
EDT editor 

selecting an EDT-like keypad in EVE, 2-2 
EISA 

bus configuration, 1-5 
ProNET interface card, 1—6 
/ENABLE qualifier, 6-3 
End-of-file errors 

CLD problem fixed, 7-6 
Entry-point directives 
when to use, 5—31 
Entry points 

when to declare, 5—31 


ERF 

See ANALYZE/ERROR utility, 4-11 
Error formatter, 6-4 
Error-handling problems fixed 
DEC C Run-Time Library, 5-8 
Error logging 

CLD problem fixed, 7-6 
Errors 

PROCINDEX, 3-5 
Ethernet 
cable, 1-4 

EVALUATE command limitation 
OpenVMS Debugger, 5-13 
EVE editor 

selecting an EDT-like keypad, 2-2 
/EXACT_ORDER qualifier, 6-8 
EXAMINE LABEL command restriction 
OpenVMS Debugger, 5-13 
Excluding devices, 6-8 
Exclusion list 
displaying, 6-9 
Execlet/driver loading 

CLD problem fixed, 7-7 
Executive 

new condition code for cross-mode page-read 
errors, 5-26 
Extended DDT bit 

problem corrected, 5-31 

F_ 

F$GETDVI lexical function, 2-3, 6-1 
F$GETSYI lexical function, 2-3 
to identify target system, 4-3 
F$SEARCH lexical function 
CLD problem fixed, 7-7 
FllCDs 

mounting noncompliant, 4-12 
/FAILUREJMODE qualifier 
SET AUDIT command, 3-35 
FDDI clusters 

restriction removed, 3-43 
FDL (File Definition Language), 5—27 
Feedback on documentation, sending to Digital, iii 
FILCNTNONZ bugcheck 
CLD problem fixed, 7-7 
File format 

compatibility in mixed-architecture VMScluster 
system, 4-3, 4-6 

Files 

opening with ASTs disabled, 7—2 
File system 

restrictions, 5-27 
support, 5-27 

/FLAG=INSTRUCTIONS qualifier, 6-3 
Floating-point return values 

requirement for “jacket”, 5-32 
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$FORMAT_AUDIT system service 
width argument, 5-41 
FORTRAN complex variables 
debugging workaround, 5-17 
FORTRAN corruption 

CLD problem fixed, 7-7 
FORTRAN programs 

qualifier needed for translated image support, 
5-43 
Full names 

support in mixed-architecture VMScluster 
system, 4-12 

Functional address mapping 
Token Ring, 1-7 
Functional equivalence 
documentation, 4-9 

OpenVMS AXP and OpenVMS VAX, 4-8 
summary, 4-15 

G_ 

$GETJPI system service 
new item code, 5-41 
$GETSYI system service, 2-3 
Global sections 

debugging not supported, 5-16 
Granularity preservation 
lost with INSV code, 5-32 
Graphics support 

on DEC 2000 systems, 1-3 
Guidelines 

application development for mixed-architecture 
VMScluster systems, 4-2 

H_ 

Hash algorithm 

security changes, 5-37 
Heap Analyzer, 4-11 
Help Message utility (MSGHLP) 
restrictions, 3-10 
.H files 

from SYS$STARLET_C.TLB to support 
DECthreads, 5-39 

provided by SYS$STARLET_C.TLB, 5-39 
$HIBER call problem and workaround 
OpenVMS Debugger, 5-18 
Host-based routing, 4-12 
HSC devices 

connected to system disks, 3-37 

l_ 

I/O bus device access 

new bus support, 5-25 
I/O fixes 

DEC C Run-Time Library, 5-5 


I/O write operations 

preventing data loss, 5-28, 5-29 
unsuccessful completion, 5-29 
Identifier attributes 
default set, 3-35 
Ident mismatch 

translated image not supported by VEST, 5-43 
IEEE floating-point standard, 5—28 
IIFs (image information files), 5-44 

provided with AXP software, 5-47, 5-48 
Image activation 

CLD problem fixed, 7-8 
Image activator, 4-9 

length comparison problem fixed, 5-28 
Image activator modified, 5-11 
Image information files 
See IIFs 

Image-naming restriction 
OpenVMS Debugger, 5-12 
Image registration, 4-12 
Images 

failure to install resident, 3-15 
Improved concurrency 

in VMScluster systems, 3-43 
Improved printf formatting of floating-point 
numbers, 5-3 
InfoServer 

DEC 10000 System restriction, 3-11 
DEC 7000 System restriction, 3-11 
losing connection, 3-11 
minimum version, 3—11 
tape support for backups, 3-5 
updating software, 3-10 
when installing on DEC 4000 system, 3-10 
Initialization 
incorrect 

recovery of root directory, 3-12 
Inlined routines 

debugging workaround, 5-16 
Installation and upgrade restrictions 
security 

auditing configuration, 3-16 
audit log files, 3-16 
audit server database files, 3-16 
audit server database name change, 3-15 
Installed resident images 
See Sliced images 

supported in the Install utility, 3-17 
Install utility 

new messages displayed by, 3-17 
support for installed resident images, 3-17 
INSV instruction 

impact on granularity, 5-32 
Internal lock manager access code 
required modification, 5-31 
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Interoperability, 6-3 

between native and translated images, 5-43 
in mixed-architecture VMScluster system, 4-2 
Intrusion 

system services, 4-10 
IO SET EXCLUDE command 
inSYSMAN, 6-8 
IO SHOW EXCLUDE command 
inSYSMAN, 6-9 
ISO 9660 

PATHWORKS access, 3-22 
restrictions, 3-22 

using /CLUSTER qualifier, 3-23 
ISO 9660 compact disc, 3-11 

J_ 

Jacket routines 

for mapping MTH$ routines to DPML 
counterparts, 5-37 

Job Process Information (JPI) utility, 6-4 
JPI$_DFMBC item code, 5-41 

K_ 

KDM70 

problem corrected, 3-45 
Kept Debugger problems and restrictions 
OpenVMS Debugger, 5-13 
Keyboard 

CLD problems fixed, 7-8 
KZMSA restriction 

problem corrected, 3-45 

L_ 

LAN CP program 

Token Ring support, 1-7 
LAT software, 3—18 
BYTLM quota, 3-18 
changes in behavior, 3-19 
restriction, 3-19 
LTA devices, 3-18 
new functions, 4—13 
startup, 3-18 
LCKMGR 

spin lock for standalone OpenVMS AXP 
systems, 5—31 

LIB$ESTABLISH system service, 7-2 
LIB$FIND_IMAGE_SYMBOL routine, 5-46 
potential DECthreads problem, 5-19 
problem corrected, 5-29 
LIBRARIAN 

error reporting problem and workaround, 5-29 

operation failure, 5—29 

performance 

CLD problem fixed, 7-8 


LICENSE command 

restriction removed, 3-20 
License Management Facility (LMF) 
for AXP systems, 3-20 
restrictions, 3-20 
/LIKE qualifier, 3-34 
Line printer device information, 6-1 
Linker utility, 6-3 

how to improve application performance, 5-30 
new error message, 5-30 
restrictions, 5-30 

workaround for restricted use of global symbols, 
5-30 

Linking overlaid program sections 
CLD problem fixed, 7-9 
Load balancing 
dynamic, 4-12 

Local area transport (LAT) software 
See LAT software 
Locking 

synchronization in mixed-architecture 
VMScluster system, 4-5, 4-7 
Lock manager 

synchronization changes, 5-31 
Logical names 

run-time libraries, 5-51 
systemwide definitions, 5-49 
longjmp function, 7-2 
lseek function, 7-2 
LTA devices 

LAT software, 3-18 
LTDRIVER restriction, 5-31 

M_ 

MACRO-32 Compiler 

/FLAGGING=INSTRUCTIONS function, 5-31 
known problem, 5-32 
restrictions, 5-32 

MACRO-64 Assembler for OpenVMS AXP Systems 
Version 1.0 

using to generate procedure signature register 
argument code, 5-2 

MAIL$USER_BEGIN overwrite problem corrected, 
5-33 

MAIL$USER_GET_INFO overwrite problem 
corrected, 5-33 
Mailbox driver 

CLD problem fixed, 7-8 
malloc function, 7-3 
M ASE $K_MA_Q 

replacement memory argument, 5-1 
MAT functions used by translated BASIC images, 
5-51 

Mathematical applications 
migrating, 5-37 
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Mathematics libraries 

VAX and AXP compatibility, 5—37 
memchr function, 7-2 
memcmp function, 7—2 
Migrating mathematical applications, 5-37 
Migrating to an OpenVMS AXP System: Porting 
VAX MACRO Code , documentation corrections, 
6-3 

Migrating to an OpenVMS AXP System: 

Recompiling and Relinking Applications, 
documentation corrections, 6-3 
Migration support 

VMScluster systems, 4-1 
Mixed-version cluster, 3-29, 3-32 
Monitoring a process during swapping 
CLD problem fixed, 7-11 
Monitoring Performance History (MPH), 3-1 
installing, 3-1 
MONITOR POOL Command 
replaced, 3-21 
MONITOR RMS command 
implemented items, 3-21 
Monitor utility (MONITOR) 
restrictions, 3-21 
version compatibility, 3—21 
Motif interface commands disabled 
OpenVMS Debugger, 5—15 
Motif interface restrictions and problems 
OpenVMS Debugger, 5—14 
Motif Version 1.1 software requirement 
OpenVMS Debugger, 5-12 
MOUNT command, 3-21 
Allocation class, 3-21 
informational message, 3-22 
MOUNT/SHARE command 

possible error in dismounting, 3-23 
Mount utility (MOUNT), 3-21 

in mixed-architecture VMScluster system, 4-13 
noncompliant FllCDs, 4—12 
MPH 

See Monitoring Performance History 
MTH$ double-precision floating-point functions 
invoked by translated images, 5-51 
MTH$ RTL, 5-37 
translated, 5—51 

N_ 

National character set (NCS), 5—27 
Native and translated images 
calls between, 5—1 
/NATIVE_ONLY qualifier, 6-3 
NCS 

See National character set 
New features 

DEC C Run-Time Library, 5-3 


Non-reentrant libraries 
CLD problem fixed, 7-8 
Null frame procedure descriptor 

potential problem to debugger, 5-32 

O_ 

Obsolete data structure cells, 5-22 
ODS-1 files, 4-13 
ODS-2 disk volumes, 3—32 
OOC$CRAM_CMD system routines 
interface change, 5-24 
Opening files with ASTs disabled, 7-2 
OpenVMS AXP operating system 
removing, 3-13 

OpenVMS AXP System-Code Debugger, 4-14 
use of, 5-25 

OpenVMS AXP Version 1.5 Release Notes, 
documentation corrections, 6-8 
OpenVMS AXP Version 6.1 New Features Manual, 
documentation corrections, 6-3 
OpenVMS Compatibility Between VAX and AXP, 
documentation corrections, 6-1 
OpenVMS DCL Dictionary, documentation 
corrections, 6—1 
OpenVMS Debugger 

commands disabled in the DECwindows Motif 
interface, 5-15 
corrections, 5-11 

DEPOSIT/TYPE command restriction, 5—17 
EVALUATE command limitation, 5—13 
$HIBER call problem and workaround, 5—18 
image-naming restriction, 5-12 
Kept Debugger problems and restrictions, 5-13 
Motif interface restrictions and problems, 5-14 
Motif Version 1.1 software requirement, 5—12 
problems and restrictions, 5-12, 5-13 
problem with analyzing process dump, 5-18 
restriction on use of EXAMINE LABEL 
command, 5-13 

restriction on use of SET BREAK 
/UNALIGNED_DATA command, 

5-13 

SHOW BREAK and SHOW TRACE command 
limitations, 5—17 

STEP command problem in system service calls, 
5-18 

STEP/INTO control loss workaround, 5—17 
STEP/OVER command error and workaround, 
5-17 

using rooted-directory logical names, 5—17 
OpenVMS Debugger Manual, documentation 
corrections, 6—1 

OpenVMS Delta /XDelta Debugger Manual, 
documentation corrections, 6—2 
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OpenVMS I/O User’s Reference Manual , 
documentation corrections, 6-2 
OpenVMS Programming Concepts Manual , 
documentation corrections, 6—6 
OpenVMS RTL String Manipulation (STR$) 
Manual , documentation corrections, 6-8 
OpenVMS System Manager’s Manual , 
documentation corrections, 6-8 
OpenVMS VAX Card Reader, Line Printer, and 
LPA11-K I/O User’s Reference Manual , 
documentation corrections, 6-1 
Operating systems 

compatibility with translated programs and 
images, 1-1 

/OPTIMIZE compiler option, 7-2 
Overflow condition, 7-3 

P_ 

Packaged files, 3-25 
Package operations problems 

with POLYCENTER Software Installation 
utility, 5—35 
/PAGE qualifier, 2-3 
Page-read error handling, 5-26 
Paging files 

CLD problem fixed, 7-1 
Password history 

creating and deleting accounts, 3—31 
lifetime change, 3-32 
Patch utility 

PATCH/ABSOLUTE function, 4-13 
PATHWORKS users 

mounting noncompliant FllCDs, 4-12 
Per-disk licensing 

volume shadowing, 6-9 
Performance degradation due to insufficient 
swapping file space, 3-23 
PIOPAGES system parameter, 3—40 
PIXSCAN priority boosts 
CLD problem fixed, 7-9 
PL/I TRANSLATE instruction 
CLD problem fixed, 7-9 

POLYCENTER Software Installation (PCSI) utility 
account removal problem, 5-35 
alternate file placement restriction, 5-33 
DCL interface, 3-24 
DECwindows Motif interface, 3-24 
disk space reporting, 3-24 
error message shortcoming, 5—33 
error reporting, 5-33 
execute statement, 5-34 
file generation number limitation, 5—34 
file generation problems, 5—34 
forward compatibility issue, 5—34 
handling managed objects, 5-33 
incompatible with VMSKITBLD.COM, 3-16 
in mixed-architecture VMScluster system, 4-13 


POLYCENTER Software Installation (PCSI) utility 
(cont’d) 

internationalization support restriction, 5-34 
network object statement, 5-34 
option statement limitation, 5-33 
packaged file sizes, 3-25 
package errors, 5-34 

potential problems with package operations, 
5-35 

PRODUCT command restriction, 3-25 
product installation restriction, 3-25 
removing products, 3-26 
restriction in deleting directories, 3-24 
rights identifier problem, 5-35 
scope support, 5-34 
“uses” clause restriction, 5-35 
Port driver $QIO 

continued restriction, 5—31 
POSIX, 7-1 
available, 1-5 
locking pages 

CLD problem fixed, 7-9 
/PRESERVE=FLOAT_EXCEPTIONS 

translation qualifier needed for TIE condition 
handler, 5-46 

PRINT/DELETE command, 3-7 
printf and scanf problems fixed 
DEC C Run-Time Library, 5—6 
printf function, 7-2 
Printing files, requirements, 3—7 
PRINT/NOTIFY command, 2-5 
PRINT/PASSALL command 
CLD problem fixed, 7-9 
PRINT/USER command 
security, 3-32 
Privilege auditing 

mixed-version cluster, 3-32 
Problems and restrictions 

DEC C Run-Time Library, 5-9 
OpenVMS Debugger, 5-12, 5-13 
Problems corrected 

DEC C Run-Time Library, 5-5 
System Dump Analyzer utility (SDA), 5-40 
Procedure descriptor, 5—32 
Procedure signature information block changes, 
5-1 

Procedure signature register argument code, 5—2 
compilers not supporting, 5-2 
Process and subprocess problems fixed 
DEC C Run-Time Library, 5—7 
Process identifiers 

limit in mixed-version VMScluster system, 4—7 
Process quotas, 3-44 
PRODUCT command 

/DEVICE restriction, 3—25 
/DIRECTORY restriction, 3-25 
/OUTPUT restriction, 3-25 
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PRODUCT REMOVE command 
files not removed with, 3—13 
removing the operating system, 3—13 
Profile changes 
security, 3-34 
Program abort hang 
DECthreads, 5-19 
Protection 

default for disk devices, 3-30 
Proxy services 
DECnet, 4-10 
PSECT keyword 

component of linker overlay restriction, 5-30 
PSIG$K_RA_I64 symbolic name no longer 
recommended, 5-2 

PSIG$K_RA_NOARG symbolic name, 5-2 
PSIG$_V_REG_ARG_INFO field 
new argument, 5-1 
PTD routines 

CLD problem fixed, 7—10 

Q_ 

QUANTUM system parameter, 3-40 
Quotas, 3-44 
QVision video cards 

DEC 2000 support, 1—3 

R_ 

Random password generator 

differences between VAX and AXP systems, 
4-13 

REAL_CPUTYPE item code, 2-3 
RECALL command 

differences between VAX and AXP systems, 
4-10 

Recovery unit journaling 
restriction, 3—26 
Register frame procedures 

debugging not fully supported, 5-16 
REGISTER_PRIVILEGED_IMAGE utility, 4-12 
Remote monitoring 
limitation, 3-21 
Remote nodes 

monitoring in a VMScluster system, 4—7 
/RESIDENT qualifier 

failure to install images with, 3—15 
using with linker command to improve 
application performance, 5-30 
Restoring files on the system disk, 3—7 
Restoring the system disk 

tape support on InfoServer systems, 3-5 
Restrictions 

backing up an AXP system disk, 3-5 
BACKUP command 

/COMPARE and /IMAGE qualifiers, 3-6 
extending index files, 3-3 


Restrictions (cont’d) 

DEC 7000 Model 600 AXP, 1-5 
DEC C Run-Time Library, 5-9 
DECnet for OpenVMS, 3-9 
DECthreads, 5-19 
file system, 5-27 
installation and upgrade 

auditing configuration, 3-16 
audit log files, 3—16 
audit server database files, 3-16 
audit server database name change, 3-15 
License Management Facility (LMF), 3-20 
Linker utility, 5-30 
MACRO-32 Compiler, 5-32 
Monitor utility, 3—21 

on passing C structure member names, 5-23 
shared linkage sections, 3-36 
Sort/Merge utility, 2-7 
symmetric multiprocessing, 3-37 
system services, 5-41 
Terminal Fallback facility, 3-42 
translated callers to CRF$FREE_VM or 
CRF$GET_VM, 5-51 
Restrictions removed 

LICENSE command, 3—20 
SCSI, 1-5 

Rights identifier problem 

with POLYCENTER Software Installation 
utility, 5-35 

RMS buffer size error changes, 5-36 
RMS Journaling 

remotely accessed files, 3-26 
restriction, 3-26 
Rolling upgrades 

in mixed-architecture VMScluster system, 4-2 
Root Directory 

incorrectly initialized, 3—12 
Rooted-directory logical names 

using with OpenVMS Debugger, 5-17 
Rounding problem and workaround 
in translated images, 5-46 
Running translated images, 5-44 

defining logical names for tranlsated libraries, 
5-44 

Run-time libraries 

accessing the D56 form, 5-51 
MTH$ RTL, 5-37 

Run-time libraries not included, 5-36 
RZ57 

volume shadowing support, 3-46 

S_ 

Satellite booting 

cross-architecture, 4-7 
scanf function, 7-3 
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SCSI (Small Computer Systems Interface) 

data check functionality restrictions removed, 

1-5 

data compaction supported by BACKUP, 3-2 
DKDRIVER restriction removed, 1-5 
restrictions on AXP systems removed, 1-5 
support on DEC 7000 Model 600 AXP, 1-5 
SCSI-2 tagged command queuing, 4-13 
SCSI controller chips 

CLD problem fixed, 7-10 
SCSI devices using LUNs 
CLD problem fixed, 7-10 
SCSI disks 

problem corrected, 3-45 
SCSI ports 

incorrect error count, 1-3 
SDA 

See System Dump Analyzer utility 
/SECTION_BINDING qualifier 

using with linker command to improve 
application performance, 5-30 
Security changes, 3-26 to 3-36 
access control entries, 3-29 
access control lists restored, 3-29 
access restriction, 3-28 
captive and restricted accounts, 3-29 
disk devices, 3-30 
hash algorithm, 5-37 
logical name table, 3-31 
mixed-version clusters, 3-29 
ODS-2 disk volumes, 3—32 
password history, 3-31 
password older than lifetime, 3-32 
preallocated disk space, 3-31 
PRINT/USER command, 3-32 
privilege auditing, 3-32 
profile changes, 3-34 
SET ACL qualifiers, 3-34 
SET AUDIT command, 3-35 
SET RIGHTS.LIST command, 3-35 
SET SECURITY command, 3-36 
SHOW SECURITY command, 3-36 
summary, 3-27 
SYS$HASH_PASSWORD, 5-37 
terminal ownership and protection, 3—34 
UAF$C_PREFERRED_ALGORITHM, 5-37 
user-mode probing of the formal parameters, 
5-38 

VMScluster requires single domain, 3-33 
volumes and devices, 3—33 
Seek past end of file, 7-3 
Seek to end of buffer, 7-2 
SET ACL command, 3-36 
/DEFAULT qualifier, 3-34 
/LIKE qualifier, 3—34 


SET AUDIT/FAILURE_MODE command, 3-35 
SET BREAK/UNALIGNED_DATA command 
restriction 

Open VMS Debugger, 5-13 
SET CONSOLE command, 1-3 
SET DEVICE/SERVED command, 2-5, 6-2 
SET PROCESS/NOAUTOJJNSHELVE command, 

2- 5 

SET PROCESS/SUSPEND=KERNEL/ID= 
command, 2-5 

SET RIGHTS_LIST/ENABLE DCL command, 

3- 35 

SET SECURITY command, 3-36 
/DEFAULT qualifier, 3-34 
/LIKE qualifier, 3-34 
SET TERMINAL command, 2-5 
SET TERMINAL/PROTOCOL=NONE command 
CLD problem fixed, 7-11 
Shadowing 

dumpfile failover, 4—13 
Shadow set members 
identical types, 3-46 
Shadow set physical devices 

MOUNT command requirement, 3-21 
SHADOW_REMOVE_l parameter, 6-9 
SHADOW_REMOVE_2 parameter, 6-9 
Shared linkage sections 
restriction, 3-36 
SHOW ACL command, 3-36 
SHOW BREAK and SHOW TRACE command 
limitations 

OpenVMS Debugger, 5-17 
SHOW CPU command, 2-6 
SHOW MACHINE.CHECK command 

enhancement to System Dump Analyzer utility 
(SDA), 5-39 

SHOW SECURITY command, 3-36 
SHOW SYSTEM command 

in mixed-architecture VMScluster system, 4-14 
Sliced images 

debugging not supported, 5-16 
SMP (symmetric multiprocessing), 3-37 

registering the SMP Extension License, 3-37 
restrictions, 3-37 
Snapshot facility (Snapshot), 4-14 
SORT command 

CLD problem fixed, 7-11 
SORT/MERGE command, 2-7 
Sort/Merge utility (SORT/MERGE) 
restrictions, 2—7 
SPAWN and LIB$SPAWN 

captive and restricted accounts, 3-29 
Spinlock changes, 5-26 
SS$_PAGRDERR 
code changed, 5-41 
Standalone BACKUP, 3-7 
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STARLET data structures and definitions 
for C programmers, 5-38 
Step 1 drivers not supported, 5-20 
Step 1 JSB-based routines obsolete, 5-21 
Step 2 driver 

requirement to recompile and relink, 5-21 
STEP command problem 

OpenVMS Debugger, 5-18 
STEP/INTO control loss workaround 
OpenVMS Debugger, 5-17 
STEP/OVER command error and workaround 
OpenVMS Debugger, 5-17 
STOP/QUEUE/RESET command, 3-8 
STR$DIVIDE routine 

CLD problem fixed, 7-11 
Stream files 

accessing, 7-2 

SUBMIT/NOTIFY command, 2-5 
Support for programs compiled against previous 
versions, 1-1 

$SUSPND system service, 2-5 
cluster problem, 5-42 
Swapping file space, related to performance 
degradation, 3-23 
Symbolic traceback, 5-42 
Symmetric multiprocessing 
See SMP 

SYS$HASH_PASS WORD 

need to recompile and relink, 5—37 
SYS$LIB_C.TLB 

problem when used with lower case, 5—9 
SYS$STARLET_C.TLB 

adherence to conventions, 5-39 
functional equivalency to STARLETSD.TLB, 
5-38 

impact on use of “variant_struct” and “variant_ 
union”, 5-38 

potential impact on LIB structures, 5—38 
potential impact on RMS structures, 5—38 
providing .H files, 5-39 
SYSMAN 

See System Management utility 
System disks 

connecting to HSC devices, 3-37 
System Dump Analyzer utility (SDA) 
access violation, 5—40 
EXAMINE problem, 5-40 
narrow display, 5—40 
problems corrected, 5-40 
SHOW MACHINE_CHECK command, 5-39 
SHOW POOL/NONPAGED command, 5-40 
System files, 6-8 

System management commands, 6-8 
System management documentation, 6-8 
System Management utility (SYSMAN), 3—37 
/CLUSTER qualifier, 3-38 


System Management utility (SYSMAN) (cont’d) 
clusterwide DISKQUOTA command 
requirement, 3-39 
DISKQUOTA commands, 3-39 
DO command, 3—38 
I/O function, 4—14 
IO SET EXCLUDE command, 6-8 
IO SHOW EXCLUDE command, 6-9 
PARAMETERS SET command, 3-38 
PARAMETERS SHOW command, 3-38 
secondary error messages missing, 3-38 
System monitoring 

See also Digital Product Performance Program 
See Monitoring Performance History 
System parameters 

ACP_DIRCACHE, 3-18 
ACP_HDRCACHE, 3-18 
ACP_MAPCACHE, 3-18 
AWSTIME, 3-40 
ITB.ENTRIES, 3-40 
PIOPAGES, 3-40 
QUANTUM, 3-40 
VIRTUALPAGECNT, 3-10 
XQPCTL2, 3-43 
System recognition 
dynamic, 4-15 
System services 

chan argument, 5-41 

changes in this version, 5—41 

$CHECK_ACCESS, 3-28 

$CHKPRO, 3-28 

condition code changed, 5-41 

$FORMAT_AUDIT problem, 5-41 

intrusion, 4-10 

LIB$ESTABLISH, 7-2 

new $GETJPI item code, 5-41 

restrictions, 5-41 

$SUSPND, 2-5 

problem calling in cluster environment, 
5-42 

Systemwide logical names, 5-49 
SYSUAF 

password history, 3-31 

T_ 

Terminal Fallback facility (TFF), 3-41 
restrictions, 3—42 

Terminal Fallback utility (TFU), 3—41 
Terminal ownership and protection, 3-34 
TFF 

See Terminal Fallback facility 
TFU 

See Terminal Fallback utility 
TIE 

See Translated Image Environment 
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TIE$EMULAT_TV.EXE image, 5-46 
TIE$SHARE shareable image, 5-43 
TMSCP tape serving, 3-44 
Token Ring 

DECnet Phase IV support, 1—9 
functional address mapping, 1-7 
LANCP program, 1-7 
support, 1-5 

TPU callable interface, 2—7 
Traceback handler support, 5—42 
/TRACEBACK option, 6-3 
Translated VAX BASIC Run-Time Library 
restrictions, 5-51 

Translated VAX COBOL programs supported, 

5-53 

Translated image 

how to debug, 5-16 

Translated Image Environment (TIE), 5-42, 5-43, 
5-45 

access violation workaround, 5—45 
interoperability between native and translated 
images, 5-43 
restrictions 

condition and exception handler, 5-45 
exception handlers that need correct PSL, 
5-45 

exception handlers that need to modify 
PSL, 5-45 
floating-point, 5-46 

handling “dirty zeros”, 5-46 
HPARITH exception workaround, 5-46 
importance of /PRE SERVE=FLOAT_ 
EXCEPTIONS qualifier, 5-46 
potential rounding problem, 5—46 
indirect call, 5-45 
interoperability, 5-45 

nonsupport of system services and run-time 
library entry points, 5-47 
translated VAX C programs, 5-46 

potential fatal memory access violation, 
5-46 

potential hang on mailbox I/O, 5-47 
running translated images, 5-44 
statistics and feedback, 5-44 
system logical names listed, 5-49 
using /TIE qualifier to enable autojacketing, 
5-45 

Translated image support, 5-42 

additional qualifier required for FORTRAN, 

5-43 

need for additional steps, 5-42 
Translated VAX C Run-Time Library, 5—52 
functional restrictions, 5-52 
interoperability restrictions, 5—53 
Translated VAX images, 6-3 
Translation 

BASIC images, 5-51 
BLAS$, 5-51 


Translation (cont’d) 

callers to CRF$FREE_VM or CRF$GET_VM, 
5-51 

executable files, 5-47 to 5-53 
images, 5-47 to 5-53 
MTHRTL, 5-51 
run-time libraries, 5-50 
TTA1 terminal port hang 
CLD problem fixed, 7-11 
TTDRIVER 

CLD problem fixed, 7-11 

u_ 

UAF$C_PREFERRED_ALGORITHM 
value changed, 5-37 

UETP (User Environment Test Package), 3-42 
creating accounts, 3-43 
UETP documentation, 3—42, 6—9 
UICs 

See User identification codes 
Unsupported elements 
programs, 1-1 
Upgrading 

unsupported versions, 3-17 
volume shadowing, 3-17 
User identification codes 
denying access with, 3-28 
User-mode probing 

conditional assembly, 5-38 
“Uses” clause restriction 

with POLYCENTER Software Installation 
utility, 5-35 

V_ 

“variant_struct” 

impact of SYS$STARLET_C.TLB, 5-38 
“variant_union” 

impact of SYS$STARLET_C.TLB, 5-38 
VAX BASIC 
See BASIC 
VAXCDEF.TLB 

replaced by new files, 5—38 
VEST, 5-43 

potential loss of run-time translation support, 
5-43 

support, 5-18 

Virtual memory corruption, 7-3 

VIRTUALPAGECNT system parameter, 3-10 

VMScluster systems, 3-43 

application development guidelines, 4-2 
CLD problems fixed, 7-11 
configuration support, 4-1 
error messages when booting, 3-15 
extending QUOTA. SYS 

CLD problem fixed, 7-10 
FDDI clusters, 3-43 
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VMScluster systems (cont’d) 
migration support, 4—1 
remote monitoring limitation, 3-21 
single security domain, 3-33 
warranted support, 4-1 
VMSINSTAL, 3-44 
VMSKITBLD.COM 

incompatible with POLYCENTER, 3-16 
Volumes and devices 
ACLs, 3-33 
Volume shadowing 

CLD problems fixed, 7-12 
corrections, 3—44 

KDM70 restriction, 3—45 
KZMSA restriction, 3-45 
SCSI disk problem, 3-45 
documentation corrections 
parameters, 6-9 
per-disk licensing, 6-9 
phase I, 3-45 
phase II, 3-45 
restrictions, 3-45 

DISMOUNT/CLUSTER command, 3-46 
phase I, 3-45 
shadow set members, 3-46 
RZ57 support, 3-46 
system boot error, 3-17 
when upgrading, 3-17 
VT500 series terminals 


baud rates supported, 3-18 

w_ 

Warranted support 

VMScluster systems, 4-1 
Watch chip (BBW) change in time range, 3-46 
Write-back caching 

change to default, 3-8 
Writeboot utility (WRITEBOOT) 

in mixed-architecture VMScluster system, 4-14 
WRTJNL_BIJ error message 

returns incorrect completion status value, 3-26 

x_ 

X/Open CAE Specification (XPG4) 
compliance with, 5-3 
XCDAC adapter, 3-47 
XQPCTL2 system parameter, 3-43 
X terminal support, 3-47 

displaying a DECwindows application, 3-47 
setting up your system, 3-47 

Y_ 

YRDRIVER 

CLD problem fixed, 7—9 
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How to Order Additional Documentation 


Technical Support 

If you need help deciding which documentation best meets your needs, call 800-DIGITAL (800-344-4825) 
and press 2 for technical assistance. 


Electronic Orders 

If you wish to place an order through your account at the Electronic Store, dial 800-234-1998, using a 
modem set to 2400- or 9600-baud. You must be using a VT terminal or terminal emulator set at 8 bits, no 
parity. If you need assistance using the Electronic Store, call 800-DIGITAL (800-344-4825) and ask for an 
Electronic Store specialist. 


Telephone and Direct Mail Orders 


From 


Call 


Write 


U.S.A. 


Puerto Rico 


Canada 


International 


Internal Orders 1 
(for software 
documentation) 


Internal Orders 
(for hardware 
documentation) 


DECdirect 

Phone: 800-DIGITAL 
(800-344-4825) 

Fax: (603) 884-5597 

Phone: (809) 781-0505 
Fax: (809) 749-8377 


Phone: 800-267-6215 
Fax: (613) 592-1946 


DTN: 264-3030 
(603) 884-3030 
Fax: (603) 884-3960 


DTN: 264-3030 
(603) 884-3030 
Fax: (603) 884-3960 


Digital Equipment Corporation 
P.O. Box CS2008 
Nashua, NH 03061 


Digital Equipment Caribbean, Inc. 

3 Digital Plaza, 1st Street 

Suite 200 

Metro Office Park 

San Juan, Puerto Rico 00920 

Digital Equipment of Canada Ltd. 
100 Herzberg Road 
Kanata, Ontario, Canada K2K 2A6 
Attn: DECdirect Sales 

Local Digital subsidiary or 
approved distributor 

U.S. Software Supply Business 
Digital Equipment Corporation 
10 Cotton Road 
Nashua, NH 03063-1260 

U.S. Software Supply Business 
Digital Equipment Corporation 
10 Cotton Road 
Nashua, NH 03063-1260 


1 Call to request an Internal Software Order Form (EN-01740-07). 
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